From owner-freebsd-hackers@FreeBSD.ORG Sun May 9 05:33:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A8CA1065670 for ; Sun, 9 May 2010 05:33:06 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id CB7BA8FC12 for ; Sun, 9 May 2010 05:33:05 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OAz8S-0007kO-Oh; Sun, 09 May 2010 05:33:04 +0000 Date: Sun, 9 May 2010 08:33:03 +0300 From: Ali Polatel To: Kostik Belousov Message-ID: <20100509053303.GD8186@harikalardiyari> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+KJYzRxRHjYqLGl5" Content-Disposition: inline In-Reply-To: <20100508123626.GC83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 09 May 2010 05:33:06 -0000 --+KJYzRxRHjYqLGl5 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik Belousov yazm=FD=FE: > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > Does FreeBSD's ptrace have a way to tell the difference between normal > > traps and those caused by a system call? > >=20 > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to t= he > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the > > syscall number when delivering system call traps, > > (i.e., deliver (SIGTRAP | 0x80)). > >=20 > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks > > related but can't be sure. > >=20 > > ?: http://linux.die.net/man/2/ptrace >=20 > There is already procfs(5)-based interface to get a reason for stop. > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. >=20 > The interface can be lifted to ptrace(2), but I think using the capacity > of procfs is not wrong there. Hmm ok, I've been playing around with PIOCSTATUS but it doesn't seem to work, there's not much documentation about it either so I figured I'll just ask. The code is here: http://alip.github.com/code/piocstatus.c The traced child is stopped at the beginning of a system call. I await that the PIOCSTATUS request sets ps.why to S_SCE but it's always zero. Can you help me figure out what I'm doing wrong? :) --=20 Regards, Ali Polatel --+KJYzRxRHjYqLGl5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvmSQ8ACgkQQU4yORhF8iByxwCgyaKIy39qr8ogM3kkDTqOrc/V /icAoLIBazca1CWCfVzQFcbnthKk+6P0 =pA9A -----END PGP SIGNATURE----- --+KJYzRxRHjYqLGl5-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 9 13:58:14 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFC311065674 for ; Sun, 9 May 2010 13:58:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4E68FC19 for ; Sun, 9 May 2010 13:58:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o49Dw73Q080738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 May 2010 16:58:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o49Dw7qk004233; Sun, 9 May 2010 16:58:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o49Dw7kT004232; Sun, 9 May 2010 16:58:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 May 2010 16:58:07 +0300 From: Kostik Belousov To: Ali Polatel Message-ID: <20100509135807.GH83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9sSKoi6Rw660DLir" Content-Disposition: inline In-Reply-To: <20100509053303.GD8186@harikalardiyari> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 09 May 2010 13:58:14 -0000 --9sSKoi6Rw660DLir Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > Kostik Belousov yazm??: > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > Does FreeBSD's ptrace have a way to tell the difference between normal > > > traps and those caused by a system call? > > >=20 > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to= the > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in = the > > > syscall number when delivering system call traps, > > > (i.e., deliver (SIGTRAP | 0x80)). > > >=20 > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks > > > related but can't be sure. > > >=20 > > > ?: http://linux.die.net/man/2/ptrace > >=20 > > There is already procfs(5)-based interface to get a reason for stop. > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > >=20 > > The interface can be lifted to ptrace(2), but I think using the capacity > > of procfs is not wrong there. >=20 > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't seem to > work, there's not much documentation about it either so I figured I'll > just ask. >=20 > The code is here: http://alip.github.com/code/piocstatus.c >=20 > The traced child is stopped at the beginning of a system call. I await > that the PIOCSTATUS request sets ps.why to S_SCE but it's always zero. > Can you help me figure out what I'm doing wrong? :) Apparently I missed the fact that S_PT_SCE and S_SCE are different flags. It seems you have to use procfs stop events (PIOCBIS) and procfs-based loop to get p_step set to 1. --9sSKoi6Rw660DLir Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvmv28ACgkQC3+MBN1Mb4jm8ACcCJiV+AcVpGvAvO/hyO+QEF/T 2rcAoMrQrd16cH5qRiENMQOhI5AwgYmG =iX9b -----END PGP SIGNATURE----- --9sSKoi6Rw660DLir-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 9 18:28:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6DEE106566B for ; Sun, 9 May 2010 18:28:56 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id 3C09D8FC12 for ; Sun, 9 May 2010 18:28:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OBBFG-0000St-MX; Sun, 09 May 2010 18:28:55 +0000 Date: Sun, 9 May 2010 21:28:51 +0300 From: Ali Polatel To: Kostik Belousov Message-ID: <20100509182851.GE8186@harikalardiyari> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tVmo9FyGdCe4F4YN" Content-Disposition: inline In-Reply-To: <20100509135807.GH83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 09 May 2010 18:28:56 -0000 --tVmo9FyGdCe4F4YN Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik Belousov yazm=FD=FE: > On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > > Kostik Belousov yazm??: > > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > > Does FreeBSD's ptrace have a way to tell the difference between nor= mal > > > > traps and those caused by a system call? > > > >=20 > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option = to the > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 i= n the > > > > syscall number when delivering system call traps, > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > >=20 > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request loo= ks > > > > related but can't be sure. > > > >=20 > > > > ?: http://linux.die.net/man/2/ptrace > > >=20 > > > There is already procfs(5)-based interface to get a reason for stop. > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > >=20 > > > The interface can be lifted to ptrace(2), but I think using the capac= ity > > > of procfs is not wrong there. > >=20 > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't seem to > > work, there's not much documentation about it either so I figured I'll > > just ask. > >=20 > > The code is here: http://alip.github.com/code/piocstatus.c > >=20 > > The traced child is stopped at the beginning of a system call. I await > > that the PIOCSTATUS request sets ps.why to S_SCE but it's always zero. > > Can you help me figure out what I'm doing wrong? :) >=20 > Apparently I missed the fact that S_PT_SCE and S_SCE are different > flags. It seems you have to use procfs stop events (PIOCBIS) and > procfs-based loop to get p_step set to 1. So I can't use ptrace() together with ioctl() based tracing. Fair enough... I'm trying to write the ioctl() based equivalent of what I've started but I can't figure out how to start tracing by forking a new child. Here's how I do it on Linux: fork() child: call kill(getpid(), SIGSTOP) and wait for the parent to resume. parent: wait for the child, set up tracing options and start tracing. I can directly use execve() so the child will stop too but I'm writing a library and for its unit tests I need to use the SIGSTOP method because I won't do any exec'ing. I tried to do the same with ioctl(), it works most of the time but it hangs every now and then at PIOCWAIT. I'm inclined to think there's a race condition but I couldn't figure out why. The code is here: http://alip.github.com/code/piocstatus-2.c Fwiw this is about a library called pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to write. Its aim is to be a lightweight portable tracing library with multiple backends (like procfs and ptrace etc.) I think this could prove useful for many people who need to do tracing and doesn't want to bother with platform specific details. --=20 Regards, Ali Polatel --tVmo9FyGdCe4F4YN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvm/uMACgkQQU4yORhF8iCZPwCgsyZ6o3UPyF+WmX5swBo4sobJ IjUAn1aJlFiESjAsf+Xs4C9XWLU5xTmd =RXqQ -----END PGP SIGNATURE----- --tVmo9FyGdCe4F4YN-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 9 21:44:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDC10106566B for ; Sun, 9 May 2010 21:44:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 264508FC08 for ; Sun, 9 May 2010 21:44:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o49Li0gN011800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 00:44:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o49Li03a006442; Mon, 10 May 2010 00:44:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o49LhxV7006441; Mon, 10 May 2010 00:43:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 May 2010 00:43:59 +0300 From: Kostik Belousov To: Ali Polatel Message-ID: <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7PTD44AewjTsiSV" Content-Disposition: inline In-Reply-To: <20100509182851.GE8186@harikalardiyari> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 09 May 2010 21:44:05 -0000 --C7PTD44AewjTsiSV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 09, 2010 at 09:28:51PM +0300, Ali Polatel wrote: > Kostik Belousov yazm??: > > On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > > > Kostik Belousov yazm??: > > > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > > > Does FreeBSD's ptrace have a way to tell the difference between n= ormal > > > > > traps and those caused by a system call? > > > > >=20 > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD optio= n to the > > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7= in the > > > > > syscall number when delivering system call traps, > > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > > >=20 > > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request l= ooks > > > > > related but can't be sure. > > > > >=20 > > > > > ?: http://linux.die.net/man/2/ptrace > > > >=20 > > > > There is already procfs(5)-based interface to get a reason for stop. > > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > > >=20 > > > > The interface can be lifted to ptrace(2), but I think using the cap= acity > > > > of procfs is not wrong there. > > >=20 > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't seem = to > > > work, there's not much documentation about it either so I figured I'll > > > just ask. > > >=20 > > > The code is here: http://alip.github.com/code/piocstatus.c > > >=20 > > > The traced child is stopped at the beginning of a system call. I await > > > that the PIOCSTATUS request sets ps.why to S_SCE but it's always zero. > > > Can you help me figure out what I'm doing wrong? :) > >=20 > > Apparently I missed the fact that S_PT_SCE and S_SCE are different > > flags. It seems you have to use procfs stop events (PIOCBIS) and > > procfs-based loop to get p_step set to 1. >=20 > So I can't use ptrace() together with ioctl() based tracing. > Fair enough... >=20 > I'm trying to write the ioctl() based equivalent of what I've started > but I can't figure out how to start tracing by forking a new child. >=20 > Here's how I do it on Linux: > fork() > child: call kill(getpid(), SIGSTOP) and wait for the parent to resume. > parent: wait for the child, set up tracing options and start tracing. >=20 > I can directly use execve() so the child will stop too but I'm writing a > library and for its unit tests I need to use the SIGSTOP method because > I won't do any exec'ing. >=20 > I tried to do the same with ioctl(), it works most of the time but it > hangs every now and then at PIOCWAIT. I'm inclined to think there's a > race condition but I couldn't figure out why. >=20 > The code is here: http://alip.github.com/code/piocstatus-2.c >=20 > Fwiw this is about a library called > pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to write. > Its aim is to be a lightweight portable tracing library with multiple > backends (like procfs and ptrace etc.) I think this could prove useful > for many people who need to do tracing and doesn't want to bother with > platform specific details. I see. You could try this patch. It requires HEAD or recent RELENG_8 to be applicable. I added PL_EVENT_SCE/SCX to PT_LWPINFO for i386 and amd64. Please note that I did not tested it, only booted the kernel to make sure that it does not break too ugly. diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index f3dba94..f97f875 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -911,6 +911,7 @@ syscall(struct trapframe *frame) if (p->p_flag & P_TRACED) { PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); } error =3D fetch_syscall_args(td, &sa); @@ -965,6 +966,11 @@ syscall(struct trapframe *frame) #endif } retval: + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -1007,12 +1013,21 @@ syscall(struct trapframe *frame) ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } /* * This works because errno is findable through the * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa.code); - PTRACESTOP_SC(p, td, S_PT_SCX); + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCX; + PROC_UNLOCK(p); + } } diff --git a/sys/amd64/ia32/ia32_syscall.c b/sys/amd64/ia32/ia32_syscall.c index aa1ae6c..300d1f6 100644 --- a/sys/amd64/ia32/ia32_syscall.c +++ b/sys/amd64/ia32/ia32_syscall.c @@ -186,6 +186,7 @@ ia32_syscall(struct trapframe *frame) if (p->p_flag & P_TRACED) { PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); } error =3D fetch_ia32_syscall_args(td, &sa); @@ -218,6 +219,11 @@ ia32_syscall(struct trapframe *frame) td->td_errno =3D error; } retval: + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -259,14 +265,23 @@ ia32_syscall(struct trapframe *frame) ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } /* * This works because errno is findable through the * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa.code); -=20 PTRACESTOP_SC(p, td, S_PT_SCX); + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCX; + PROC_UNLOCK(p); + } } =20 =20 diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c index a11daa6..2550d34 100644 --- a/sys/i386/i386/trap.c +++ b/sys/i386/i386/trap.c @@ -1170,13 +1170,22 @@ syscall(struct trapframe *frame) ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } /* * This works because errno is findable through the * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa.code); - PTRACESTOP_SC(p, td, S_PT_SCX); + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCX; + PROC_UNLOCK(p); + } } =20 diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index d8cc4f0..a6b88c3 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -1105,6 +1105,10 @@ kern_ptrace(struct thread *td, int req, pid_t pid, v= oid *addr, int data) pl->pl_lwpid =3D td2->td_tid; if (td2->td_dbgflags & TDB_XSIG) pl->pl_event =3D PL_EVENT_SIGNAL; + else if (td2->td_dbgflags & TDB_SCE) + pl->pl_event =3D PL_EVENT_SCE; + else if (td2->td_dbgflags & TDB_SCX) + pl->pl_event =3D PL_EVENT_SCX; else pl->pl_event =3D 0; pl->pl_flags =3D 0; diff --git a/sys/sys/proc.h b/sys/sys/proc.h index e32e494..9457ad1 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -364,6 +364,8 @@ do { \ #define TDB_SUSPEND 0x00000001 /* Thread is suspended by debugger */ #define TDB_XSIG 0x00000002 /* Thread is exchanging signal under trace */ #define TDB_USERWR 0x00000004 /* Debugger modified memory or registers */ +#define TDB_SCE 0x00000008 /* Thread performs syscall enter */ +#define TDB_SCX 0x00000010 /* Thread performs syscall exit */ =20 /* * "Private" flags kept in td_pflags: diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h index b30447c..3265e63 100644 --- a/sys/sys/ptrace.h +++ b/sys/sys/ptrace.h @@ -96,6 +96,8 @@ struct ptrace_lwpinfo { int pl_event; /* Event that stopped the LWP. */ #define PL_EVENT_NONE 0 #define PL_EVENT_SIGNAL 1 +#define PL_EVENT_SCE 2 +#define PL_EVENT_SCX 3 int pl_flags; /* LWP flags. */ #define PL_FLAG_SA 0x01 /* M:N thread */ #define PL_FLAG_BOUND 0x02 /* M:N bound thread */ --C7PTD44AewjTsiSV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvnLJ8ACgkQC3+MBN1Mb4g9SgCfddSBqrVeOWqlXjLuRrKWvwAK nnwAn3YOWzugd7p3ViKHwNZEIXE0YlJz =JhPv -----END PGP SIGNATURE----- --C7PTD44AewjTsiSV-- From owner-freebsd-hackers@FreeBSD.ORG Sun May 9 22:16:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CEBF106564A; Sun, 9 May 2010 22:16:25 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id E67DE8FC0C; Sun, 9 May 2010 22:16:24 +0000 (UTC) Received: from baby-jane.lamaiziere.net (unknown [192.168.1.10]) by smtp.lamaiziere.net (Postfix) with ESMTP id 591D263307D; Mon, 10 May 2010 00:16:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 97A352CEC17; Mon, 10 May 2010 00:16:38 +0200 (CEST) Date: Mon, 10 May 2010 00:16:37 +0200 From: Patrick Lamaiziere To: Oleksandr Tymoshenko Message-ID: <20100510001637.2a564cd5@davenulle.org> In-Reply-To: <4BE46650.7010008@bluezbox.com> References: <4BE46650.7010008@bluezbox.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Sam Leffler Subject: Re: hifn(4) DMA fix for review 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, 09 May 2010 22:16:25 -0000 Le Fri, 07 May 2010 12:13:20 -0700, Oleksandr Tymoshenko a écrit : Hi, > Proposed patch addresses hifn(4) problems on FreeBSD/mips. > Current implementation keeps some of the state information (indexes in > buffers, etc) in DMA-mapped memory and bus_dma code invalidates them > during sync operations. This fix moves data that doesn't belong to DMA > ring to softc structure. I do not have any comment but I will try on my Soekris (the next weekend) if it can help. I noticed several things in hifn, if you want to look: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130286 IMHO some locks are missing in the use of sc->sc_sessions (the array containing the sessions) : in hifn_newsession(), if there is no space left in sc->sc_sessions, a new array is allocated and the sessions are copied to it. Unfortunaly, sc->sc_sessions is used in hifn_process without any lock and we use some pointers on the array (my patch should addresses this if I remember...). Regards. From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 08:15:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86F191065677 for ; Mon, 10 May 2010 08:15:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 467318FC22 for ; Mon, 10 May 2010 08:15:05 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (85-142-52-164.well-com.net [85.142.52.164]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 0612213DF48 for ; Mon, 10 May 2010 11:57:16 +0400 (MSD) Date: Mon, 10 May 2010 11:57:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1127023465.20100510115708@serebryakov.spb.ru> To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: How to get stack bounds of current process? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 08:15:05 -0000 Hello, Freebsd-hackers. I'm proting some application from Linux, which discover its stack bounds by reading and pasing "/proc/self/maps". FreeBSD have "/prov/curproc/map", but I can not find how to determine which record is for stack (I've looked into implementation of proc_fs, but it doesn't contain any specail processing for process stack). How could I determine stack bounds of current process on FreeBSD 7/8/9? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 14:58:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B89410657A4 for ; Mon, 10 May 2010 14:58:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 785C08FC13 for ; Mon, 10 May 2010 14:58:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4AEwH7r083238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 17:58:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4AEwHAg011619; Mon, 10 May 2010 17:58:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4AEwHGp011618; Mon, 10 May 2010 17:58:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 May 2010 17:58:17 +0300 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20100510145817.GO83316@deviant.kiev.zoral.com.ua> References: <1127023465.20100510115708@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NT59pYSnj1ZLVgEN" Content-Disposition: inline In-Reply-To: <1127023465.20100510115708@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: How to get stack bounds of current process? 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, 10 May 2010 14:58:22 -0000 --NT59pYSnj1ZLVgEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 11:57:08AM +0400, Lev Serebryakov wrote: > Hello, Freebsd-hackers. >=20 > I'm proting some application from Linux, which discover its stack > bounds by reading and pasing "/proc/self/maps". FreeBSD have > "/prov/curproc/map", but I can not find how to determine which record > is for stack (I've looked into implementation of proc_fs, but it > doesn't contain any specail processing for process stack). >=20 > How could I determine stack bounds of current process on FreeBSD > 7/8/9? I think the right question is why the program needs the information at all. Really, the system has no data to answer your question. Which stack are you asking for ? The stack of main thread, set up by kernel, is very different from the stack established by the threading library for newly created thread. What should happen for signal altstacks ? Also, the threading library clips the main thread stack to match its size with default stack size (I do think this is unsafe and wrong). Also, the application can legitimately allocate arbitrary memory region and use it as the stack (this is essentially what threading library does). --NT59pYSnj1ZLVgEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvoHwgACgkQC3+MBN1Mb4jjIgCgyFjGlYaXqAWix7L3+8ck83nx hHIAoOsVsn68hXRCYQIk3P3v7EWbrzSJ =yJWW -----END PGP SIGNATURE----- --NT59pYSnj1ZLVgEN-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 15:35:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B64D2106564A for ; Mon, 10 May 2010 15:35:44 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8BED88FC14 for ; Mon, 10 May 2010 15:35:44 +0000 (UTC) Received: from [172.24.98.37] ([192.75.139.252]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o4AFNnlI056269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 08:23:52 -0700 (PDT) (envelope-from sam@errno.com) Message-Id: <892C86B0-81B0-433D-BF9C-7CDBD479F6CC@errno.com> From: Sam Leffler To: Oleksandr Tymoshenko In-Reply-To: <4BE46650.7010008@bluezbox.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 May 2010 08:23:48 -0700 References: <4BE46650.7010008@bluezbox.com> X-Mailer: Apple Mail (2.936) X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org Subject: Re: hifn(4) DMA fix for review 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, 10 May 2010 15:35:44 -0000 On May 7, 2010, at 12:13 PM, Oleksandr Tymoshenko wrote: > Proposed patch addresses hifn(4) problems on FreeBSD/mips. Current > implementation keeps some of the state information (indexes in > buffers, etc) in DMA-mapped memory and bus_dma code invalidates them > during sync operations. This fix moves data that doesn't belong to DMA > ring to softc structure. > > Patch: http://people.freebsd.org/~gonzo/hifn.diff > Stats for original driver: > http://people.freebsd.org/~gonzo/hifn.stats.orig.txt > Stats for patched version: > http://people.freebsd.org/~gonzo/hifn.stats.patched.txt > > The changes look fine and make sense (did something similar for some other drivers for when the dma data structures were mapped uncached). I can't see any performance change in your stats; but I'm just eyeballing the numbers side-by-side. Was this on x86? (where there should be zero difference) It would be good to present these numbers better (e.g. curves on the same graph, ministat output, etc). Sam From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 15:35:45 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 202291065670 for ; Mon, 10 May 2010 15:35:45 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id EA7038FC15 for ; Mon, 10 May 2010 15:35:44 +0000 (UTC) Received: from [172.24.98.37] ([192.75.139.252]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o4AFQ9fr056289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 08:26:11 -0700 (PDT) (envelope-from sam@errno.com) Message-Id: From: Sam Leffler To: Patrick Lamaiziere In-Reply-To: <20100510001637.2a564cd5@davenulle.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 May 2010 08:26:08 -0700 References: <4BE46650.7010008@bluezbox.com> <20100510001637.2a564cd5@davenulle.org> X-Mailer: Apple Mail (2.936) X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org Subject: Re: hifn(4) DMA fix for review 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, 10 May 2010 15:35:45 -0000 On May 9, 2010, at 3:16 PM, Patrick Lamaiziere wrote: > Le Fri, 07 May 2010 12:13:20 -0700, > Oleksandr Tymoshenko a =E9crit : > > Hi, > >> Proposed patch addresses hifn(4) problems on FreeBSD/mips. >> Current implementation keeps some of the state information (indexes =20= >> in >> buffers, etc) in DMA-mapped memory and bus_dma code invalidates them >> during sync operations. This fix moves data that doesn't belong to =20= >> DMA >> ring to softc structure. > > I do not have any comment but I will try on my Soekris (the next > weekend) if it can help. > > I noticed several things in hifn, if you want to look: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130286 > > IMHO some locks are missing in the use of sc->sc_sessions (the array > containing the sessions) : in hifn_newsession(), if there is no space > left in sc->sc_sessions, a new array is allocated and the sessions are > copied to it. Unfortunaly, sc->sc_sessions is used in hifn_process > without any lock and we use some pointers on the array (my patch =20 > should > addresses this if I remember...). Isn't this just the glx locking? (no offense intended) I've said =20 before I think we to move session management up into the crypto layer =20= since it's implemented in many drivers (usually w/ c&p of the same =20 code as you noted here sometimes a bit different). Sam From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 16:48:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E64331065677 for ; Mon, 10 May 2010 16:48:26 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id 64F908FC0A for ; Mon, 10 May 2010 16:48:26 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id CFAA52A28CF3; Mon, 10 May 2010 18:32:37 +0200 (CEST) Date: Mon, 10 May 2010 18:32:37 +0200 From: Ed Schouten To: Dmitry Krivenok Message-ID: <20100510163237.GU56080@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YfA6L/ars3kY+zmg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit) 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, 10 May 2010 16:48:27 -0000 --YfA6L/ars3kY+zmg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Dmitry Krivenok wrote: > - int dev_num =3D minor(dev); > + int dev_num =3D minor(dev2unit(dev)); Almost there. Just remove all calls to unit2minor() and minor2unit() (if present) and replace minor() with dev2unit(): int dev_num =3D dev2unit(dev); But even better, don't use device unit numbers at all. The struct cdev already provides fields like si_drv1 and si_drv2 that can be used to store per-device data. Some drivers use constructs like these: sc =3D device_get_softc(devclass_get_device(devclass, dev2unit(cdev))); In those cases the code should just be changed to do something similar to the following: cdev =3D make_dev(....); cdev->si_drv1 =3D sc; Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --YfA6L/ars3kY+zmg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvoNSUACgkQ52SDGA2eCwUXrACfXuLNr/qg1T3aNAs2A4GaYwvm +KgAn0cBgR1yY56/u/DTJdDJ4b2nVHg3 =l2uq -----END PGP SIGNATURE----- --YfA6L/ars3kY+zmg-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 16:48:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C99451065686 for ; Mon, 10 May 2010 16:48:50 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9FD8FC0A for ; Mon, 10 May 2010 16:48:50 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OBW9w-0003BG-U1; Mon, 10 May 2010 16:48:49 +0000 Date: Mon, 10 May 2010 19:48:47 +0300 From: Ali Polatel To: Kostik Belousov Message-ID: <20100510164847.GF8186@harikalardiyari> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wtjvnLv0o8UUzur2" Content-Disposition: inline In-Reply-To: <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 10 May 2010 16:48:50 -0000 --wtjvnLv0o8UUzur2 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik Belousov yazm=FD=FE: > On Sun, May 09, 2010 at 09:28:51PM +0300, Ali Polatel wrote: > > Kostik Belousov yazm??: > > > On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > > > > Kostik Belousov yazm??: > > > > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > > > > Does FreeBSD's ptrace have a way to tell the difference between= normal > > > > > > traps and those caused by a system call? > > > > > >=20 > > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD opt= ion to the > > > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit= 7 in the > > > > > > syscall number when delivering system call traps, > > > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > > > >=20 > > > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request= looks > > > > > > related but can't be sure. > > > > > >=20 > > > > > > ?: http://linux.die.net/man/2/ptrace > > > > >=20 > > > > > There is already procfs(5)-based interface to get a reason for st= op. > > > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > > > >=20 > > > > > The interface can be lifted to ptrace(2), but I think using the c= apacity > > > > > of procfs is not wrong there. > > > >=20 > > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't see= m to > > > > work, there's not much documentation about it either so I figured I= 'll > > > > just ask. > > > >=20 > > > > The code is here: http://alip.github.com/code/piocstatus.c > > > >=20 > > > > The traced child is stopped at the beginning of a system call. I aw= ait > > > > that the PIOCSTATUS request sets ps.why to S_SCE but it's always ze= ro. > > > > Can you help me figure out what I'm doing wrong? :) > > >=20 > > > Apparently I missed the fact that S_PT_SCE and S_SCE are different > > > flags. It seems you have to use procfs stop events (PIOCBIS) and > > > procfs-based loop to get p_step set to 1. > >=20 > > So I can't use ptrace() together with ioctl() based tracing. > > Fair enough... > >=20 > > I'm trying to write the ioctl() based equivalent of what I've started > > but I can't figure out how to start tracing by forking a new child. > >=20 > > Here's how I do it on Linux: > > fork() > > child: call kill(getpid(), SIGSTOP) and wait for the parent to resume. > > parent: wait for the child, set up tracing options and start tracing. > >=20 > > I can directly use execve() so the child will stop too but I'm writing a > > library and for its unit tests I need to use the SIGSTOP method because > > I won't do any exec'ing. > >=20 > > I tried to do the same with ioctl(), it works most of the time but it > > hangs every now and then at PIOCWAIT. I'm inclined to think there's a > > race condition but I couldn't figure out why. > >=20 > > The code is here: http://alip.github.com/code/piocstatus-2.c > >=20 > > Fwiw this is about a library called > > pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to write. > > Its aim is to be a lightweight portable tracing library with multiple > > backends (like procfs and ptrace etc.) I think this could prove useful > > for many people who need to do tracing and doesn't want to bother with > > platform specific details. >=20 > I see. You could try this patch. It requires HEAD or recent RELENG_8 > to be applicable. I added PL_EVENT_SCE/SCX to PT_LWPINFO for i386 and > amd64. Please note that I did not tested it, only booted the kernel to > make sure that it does not break too ugly. >=20 > diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c > index f3dba94..f97f875 100644 Looks great, I could only test it basically but it seems to work fine. If this is merged, truss can make use of this too. Another question is how hard is it to implement PL_EVENT_EXEC? This could be useful for truss as it updates the execution type of the process after successful execve() calls afaict. --=20 Regards, Ali Polatel --wtjvnLv0o8UUzur2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvoOO8ACgkQQU4yORhF8iCtqwCeK9cYJKBLwt6oK9RP+8wJBnpQ GR8AoKee33R8M0oLdf683WIkxKo0aBWR =GWan -----END PGP SIGNATURE----- --wtjvnLv0o8UUzur2-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 17:09:57 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 325C9106564A for ; Mon, 10 May 2010 17:09:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C26CE8FC18 for ; Mon, 10 May 2010 17:09:56 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4AH9loU092262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 20:09:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4AH9lPa012338; Mon, 10 May 2010 20:09:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4AH9lT5012337; Mon, 10 May 2010 20:09:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 May 2010 20:09:47 +0300 From: Kostik Belousov To: Ali Polatel Message-ID: <20100510170947.GP83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> <20100510164847.GF8186@harikalardiyari> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r/w8vo2lxBmCPGjQ" Content-Disposition: inline In-Reply-To: <20100510164847.GF8186@harikalardiyari> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 10 May 2010 17:09:57 -0000 --r/w8vo2lxBmCPGjQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 07:48:47PM +0300, Ali Polatel wrote: > Kostik Belousov yazm??: > > On Sun, May 09, 2010 at 09:28:51PM +0300, Ali Polatel wrote: > > > Kostik Belousov yazm??: > > > > On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > > > > > Kostik Belousov yazm??: > > > > > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > > > > > Does FreeBSD's ptrace have a way to tell the difference betwe= en normal > > > > > > > traps and those caused by a system call? > > > > > > >=20 > > > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD o= ption to the > > > > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set b= it 7 in the > > > > > > > syscall number when delivering system call traps, > > > > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > > > > >=20 > > > > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO reque= st looks > > > > > > > related but can't be sure. > > > > > > >=20 > > > > > > > ?: http://linux.die.net/man/2/ptrace > > > > > >=20 > > > > > > There is already procfs(5)-based interface to get a reason for = stop. > > > > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > > > > >=20 > > > > > > The interface can be lifted to ptrace(2), but I think using the= capacity > > > > > > of procfs is not wrong there. > > > > >=20 > > > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't s= eem to > > > > > work, there's not much documentation about it either so I figured= I'll > > > > > just ask. > > > > >=20 > > > > > The code is here: http://alip.github.com/code/piocstatus.c > > > > >=20 > > > > > The traced child is stopped at the beginning of a system call. I = await > > > > > that the PIOCSTATUS request sets ps.why to S_SCE but it's always = zero. > > > > > Can you help me figure out what I'm doing wrong? :) > > > >=20 > > > > Apparently I missed the fact that S_PT_SCE and S_SCE are different > > > > flags. It seems you have to use procfs stop events (PIOCBIS) and > > > > procfs-based loop to get p_step set to 1. > > >=20 > > > So I can't use ptrace() together with ioctl() based tracing. > > > Fair enough... > > >=20 > > > I'm trying to write the ioctl() based equivalent of what I've started > > > but I can't figure out how to start tracing by forking a new child. > > >=20 > > > Here's how I do it on Linux: > > > fork() > > > child: call kill(getpid(), SIGSTOP) and wait for the parent to resum= e. > > > parent: wait for the child, set up tracing options and start tracing. > > >=20 > > > I can directly use execve() so the child will stop too but I'm writin= g a > > > library and for its unit tests I need to use the SIGSTOP method becau= se > > > I won't do any exec'ing. > > >=20 > > > I tried to do the same with ioctl(), it works most of the time but it > > > hangs every now and then at PIOCWAIT. I'm inclined to think there's a > > > race condition but I couldn't figure out why. > > >=20 > > > The code is here: http://alip.github.com/code/piocstatus-2.c > > >=20 > > > Fwiw this is about a library called > > > pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to write. > > > Its aim is to be a lightweight portable tracing library with multiple > > > backends (like procfs and ptrace etc.) I think this could prove useful > > > for many people who need to do tracing and doesn't want to bother with > > > platform specific details. > >=20 > > I see. You could try this patch. It requires HEAD or recent RELENG_8 > > to be applicable. I added PL_EVENT_SCE/SCX to PT_LWPINFO for i386 and > > amd64. Please note that I did not tested it, only booted the kernel to > > make sure that it does not break too ugly. > >=20 > > diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c > > index f3dba94..f97f875 100644 > >=20 > Looks great, I could only test it basically but it seems to work fine. > If this is merged, truss can make use of this too. >=20 > Another question is how hard is it to implement PL_EVENT_EXEC? > This could be useful for truss as it updates the execution type of the > process after successful execve() calls afaict. Is this needed ? The question is not rhetorical, I am trying to understand what prevents use of PT_TO_SCE and checking the syscall number ? You would screen for SYS_execve or SYS_fexecve and reset the debugger state on SIGTRAP that is supplied to the debugger before first instruction of new image is executed. Can you, please, extract and provide me with the code you used to test the PL_EVENT_SCE/SCX patch ? --r/w8vo2lxBmCPGjQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvoPdoACgkQC3+MBN1Mb4jitACgzfaQqgRwIkqxRKy8YVWQe1UF +q4AoLT1uZ9D2PWIBo8PAzw8Dac89t8c =lDGb -----END PGP SIGNATURE----- --r/w8vo2lxBmCPGjQ-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 17:45:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B22C1065672; Mon, 10 May 2010 17:45:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 037628FC1C; Mon, 10 May 2010 17:45:30 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (85-142-52-164.well-com.net [85.142.52.164]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 975B013DF46; Mon, 10 May 2010 21:45:29 +0400 (MSD) Date: Mon, 10 May 2010 21:45:21 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1638216268.20100510214521@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20100510145817.GO83316@deviant.kiev.zoral.com.ua> References: <1127023465.20100510115708@serebryakov.spb.ru> <20100510145817.GO83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Lev Serebryakov Subject: Re: How to get stack bounds of current process? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:45:31 -0000 Hello, Kostik. You wrote 10 =EC=E0=FF 2010 =E3., 18:58:17: >> I'm proting some application from Linux, which discover its stack >> bounds by reading and pasing "/proc/self/maps". FreeBSD have >> "/prov/curproc/map", but I can not find how to determine which record >> is for stack (I've looked into implementation of proc_fs, but it >> doesn't contain any specail processing for process stack). >>=20 >> How could I determine stack bounds of current process on FreeBSD >> 7/8/9? > I think the right question is why the program needs the information at al= l. > Really, the system has no data to answer your question. Which stack are > you asking for ? The stack of main thread, set up by kernel, is very > different from the stack established by the threading library for > newly created thread. What should happen for signal altstacks ? > Also, the threading library clips the main thread stack to match its > size with default stack size (I do think this is unsafe and wrong). It is port of new openjdk7 build. It adds function with this comment in Linux-specific code (BSD port is based on Linux one): // Linux uses a growable mapping for the stack, and if the mapping for // the stack guard pages is not removed when we detach a thread the // stack cannot grow beyond the pages where the stack guard was // mapped. If at some point later in the process the stack expands to // that point, the Bsd kernel cannot expand the stack any further // because the guard pages are in the way, and a segfault occurs. // // However, it's essential not to split the stack region by unmapping // a region (leaving a hole) that's already part of the stack mapping, // so if the stack mapping has already grown beyond the guard pages at // the time we create them, we have to truncate the stack mapping. // So, we need to know the extent of the stack mapping when // create_stack_guard_pages() is called. // Find the bounds of the stack mapping. Return true for success. // // We only need this for stacks that are growable: at the time of // writing thread stacks don't use growable mappings (i.e. those // creeated with MAP_GROWSDOWN), and aren't marked "[stack]", so this // only applies to the main thread. // If the (growable) stack mapping already extends beyond the point // where we're going to put our guard pages, truncate the mapping at // that point by munmap()ping it. This ensures that when we later // munmap() the guard pages we don't leave a hole in the stack // mapping. Solaris code simple map/unmap needed pages, and Linux port checks stack region and applies special processing for growable stack area... I'm not sure, should BSD port behaves as Linux or as Solaris one. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 19:09:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3E3E1065678; Mon, 10 May 2010 19:09:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF878FC0A; Mon, 10 May 2010 19:09:42 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4AJ9c1N001253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 22:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4AJ9cI8013072; Mon, 10 May 2010 22:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4AJ9cnK013071; Mon, 10 May 2010 22:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 May 2010 22:09:38 +0300 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20100510190938.GR83316@deviant.kiev.zoral.com.ua> References: <1127023465.20100510115708@serebryakov.spb.ru> <20100510145817.GO83316@deviant.kiev.zoral.com.ua> <1638216268.20100510214521@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FWibJpkbnkY6rrXF" Content-Disposition: inline In-Reply-To: <1638216268.20100510214521@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: How to get stack bounds of current process? 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, 10 May 2010 19:09:42 -0000 --FWibJpkbnkY6rrXF Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 09:45:21PM +0400, Lev Serebryakov wrote: > Hello, Kostik. > You wrote 10 =CD=C1=D1 2010 =C7., 18:58:17: >=20 >=20 > >> I'm proting some application from Linux, which discover its stack > >> bounds by reading and pasing "/proc/self/maps". FreeBSD have > >> "/prov/curproc/map", but I can not find how to determine which record > >> is for stack (I've looked into implementation of proc_fs, but it > >> doesn't contain any specail processing for process stack). > >>=20 > >> How could I determine stack bounds of current process on FreeBSD > >> 7/8/9? > > I think the right question is why the program needs the information at = all. >=20 > > Really, the system has no data to answer your question. Which stack are > > you asking for ? The stack of main thread, set up by kernel, is very > > different from the stack established by the threading library for > > newly created thread. What should happen for signal altstacks ? > > Also, the threading library clips the main thread stack to match its > > size with default stack size (I do think this is unsafe and wrong). > It is port of new openjdk7 build. It adds function with > this comment in Linux-specific code (BSD port is based on Linux one): >=20 > // Linux uses a growable mapping for the stack, and if the mapping for > // the stack guard pages is not removed when we detach a thread the > // stack cannot grow beyond the pages where the stack guard was > // mapped. If at some point later in the process the stack expands to > // that point, the Bsd kernel cannot expand the stack any further > // because the guard pages are in the way, and a segfault occurs. > // > // However, it's essential not to split the stack region by unmapping > // a region (leaving a hole) that's already part of the stack mapping, > // so if the stack mapping has already grown beyond the guard pages at > // the time we create them, we have to truncate the stack mapping. > // So, we need to know the extent of the stack mapping when > // create_stack_guard_pages() is called. >=20 > // Find the bounds of the stack mapping. Return true for success. > // > // We only need this for stacks that are growable: at the time of > // writing thread stacks don't use growable mappings (i.e. those > // creeated with MAP_GROWSDOWN), and aren't marked "[stack]", so this > // only applies to the main thread. >=20 > // If the (growable) stack mapping already extends beyond the point > // where we're going to put our guard pages, truncate the mapping at > // that point by munmap()ping it. This ensures that when we later > // munmap() the guard pages we don't leave a hole in the stack > // mapping. >=20 > Solaris code simple map/unmap needed pages, and Linux port > checks stack region and applies special processing for growable stack > area... >=20 > I'm not sure, should BSD port behaves as Linux or as Solaris one. I still do not understand what the program does and why. Text you posted assumes reader understands what the code does and what goals are achieved there. I did mentioned that the threading library puts unmapped region to clip the main thread stack, is this the issue the author of comment worried ? And why this makes him worry ? --FWibJpkbnkY6rrXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvoWfEACgkQC3+MBN1Mb4hSpACfXxgsW2x+uvpyPl5e8mRfifk1 aaIAoKWhNKEymJixaVWvnY3s5kEwVH4E =8LUr -----END PGP SIGNATURE----- --FWibJpkbnkY6rrXF-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 19:09:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2654C1065674 for ; Mon, 10 May 2010 19:09:47 +0000 (UTC) (envelope-from thespin@gmail.com) Received: from mail-yx0-f175.google.com (mail-yx0-f175.google.com [209.85.210.175]) by mx1.freebsd.org (Postfix) with ESMTP id D9D578FC1A for ; Mon, 10 May 2010 19:09:46 +0000 (UTC) Received: by yxe5 with SMTP id 5so1953724yxe.3 for ; Mon, 10 May 2010 12:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=NOFSRbnKqRv4s+EmAp1avtebv6uEDhltV+ymAD2SROk=; b=rfdwEaNv5jlQjPc6zoYItJwZuVH7PZaHVx074YpkAw2r6mG7QEAjzCFb85merSCA3i NaDM6yX6t62JK+5ZGV5iImZZbN3phPF0UVFSNpZ7oCmJk8FJS4qac+hxnyKQXHeGNexD uoyRa0ZMEPjHVHLnSOLJIjLL6FHVqqI1dKcrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Txxyax+HhzWCPYdR8NY3kUPomstqYvExnZ4XGhvSTFtAAw+WmIoCykTlRkQ5cOS28k ru4llSf1pWqkPkGeW8Jd0RvDhoUseQgs8ugS90bkVVK6jyrD8xavsVBUm7vgA2cu1ZQ0 pwjMTrr0+wKP1EMnCuhIJgDMYESuR6q84WpUw= MIME-Version: 1.0 Received: by 10.231.79.144 with SMTP id p16mr3176003ibk.4.1273516946751; Mon, 10 May 2010 11:42:26 -0700 (PDT) Received: by 10.231.12.129 with HTTP; Mon, 10 May 2010 11:42:26 -0700 (PDT) Date: Mon, 10 May 2010 11:42:26 -0700 Message-ID: From: Evan Geller To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Recursion in the UVA 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, 10 May 2010 19:09:47 -0000 I'm a bit confused how recursion in the UVA works. vm_map_entries are allocated from a vm_map_entry zone, but if the vm_map_entry slabs are full and it needs to allocate a vm_map_entry to satisfy the mapping, there would seem to be a starvation. I also see a uk_recurse field per keg that gets increased when calling back in... but I don't exactly understand what goes on after the NULL is returned. I'm also a bit confused about the difference between a keg, a zone, and a slab... the classic definition of the slab is the per-object cache with slabs... I'm having trouble understanding what the 3 level structure gets you. -- --- Evan Geller thespin@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 07:45:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C368E1065672; Tue, 11 May 2010 07:45:34 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 96B3B8FC0C; Tue, 11 May 2010 07:45:34 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o4B7BIGC072777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 May 2010 00:11:18 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o4B7BIAp072776; Tue, 11 May 2010 00:11:18 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08232; Tue, 11 May 10 00:00:32 PDT Date: Mon, 10 May 2010 23:58:33 -0700 From: perryh@pluto.rain.com To: kostikbel@gmail.com, lev@freebsd.org Message-Id: <4be90019.0XTfjCaL4QZtrIs9%perryh@pluto.rain.com> References: <1127023465.20100510115708@serebryakov.spb.ru> <20100510145817.GO83316@deviant.kiev.zoral.com.ua> <1638216268.20100510214521@serebryakov.spb.ru> In-Reply-To: <1638216268.20100510214521@serebryakov.spb.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to get stack bounds of current process? 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, 11 May 2010 07:45:34 -0000 Lev Serebryakov wrote: > I'm not sure, should BSD port behaves as Linux or as > Solaris one. Based solely on heritage, I suspect the Solaris approach might fit more comfortably. Solaris comes from SVR4, which was supposed to be the great reunification of SysV and BSD, and so has 4.3 BSD in its ancestry -- as does FreeBSD. Linux is a "from scratch" reimplementation of the SVID which deliberately included no SysV or BSD code. From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 10:35:04 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 436DF106566C for ; Tue, 11 May 2010 10:35:04 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id B5D268FC1A for ; Tue, 11 May 2010 10:35:02 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OBmnl-0008N6-Cn; Tue, 11 May 2010 10:35:01 +0000 Date: Tue, 11 May 2010 13:35:00 +0300 From: Ali Polatel To: Kostik Belousov Message-ID: <20100511103500.GH8186@harikalardiyari> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> <20100510164847.GF8186@harikalardiyari> <20100510170947.GP83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w2JjAQZceEVGylhD" Content-Disposition: inline In-Reply-To: <20100510170947.GP83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 11 May 2010 10:35:04 -0000 --w2JjAQZceEVGylhD Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik Belousov yazm=FD=FE: > On Mon, May 10, 2010 at 07:48:47PM +0300, Ali Polatel wrote: > > Kostik Belousov yazm??: > > > On Sun, May 09, 2010 at 09:28:51PM +0300, Ali Polatel wrote: > > > > Kostik Belousov yazm??: > > > > > On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > > > > > > Kostik Belousov yazm??: > > > > > > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > > > > > > Does FreeBSD's ptrace have a way to tell the difference bet= ween normal > > > > > > > > traps and those caused by a system call? > > > > > > > >=20 > > > > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD= option to the > > > > > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set= bit 7 in the > > > > > > > > syscall number when delivering system call traps, > > > > > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > > > > > >=20 > > > > > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO req= uest looks > > > > > > > > related but can't be sure. > > > > > > > >=20 > > > > > > > > ?: http://linux.die.net/man/2/ptrace > > > > > > >=20 > > > > > > > There is already procfs(5)-based interface to get a reason fo= r stop. > > > > > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > > > > > >=20 > > > > > > > The interface can be lifted to ptrace(2), but I think using t= he capacity > > > > > > > of procfs is not wrong there. > > > > > >=20 > > > > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't= seem to > > > > > > work, there's not much documentation about it either so I figur= ed I'll > > > > > > just ask. > > > > > >=20 > > > > > > The code is here: http://alip.github.com/code/piocstatus.c > > > > > >=20 > > > > > > The traced child is stopped at the beginning of a system call. = I await > > > > > > that the PIOCSTATUS request sets ps.why to S_SCE but it's alway= s zero. > > > > > > Can you help me figure out what I'm doing wrong? :) > > > > >=20 > > > > > Apparently I missed the fact that S_PT_SCE and S_SCE are different > > > > > flags. It seems you have to use procfs stop events (PIOCBIS) and > > > > > procfs-based loop to get p_step set to 1. > > > >=20 > > > > So I can't use ptrace() together with ioctl() based tracing. > > > > Fair enough... > > > >=20 > > > > I'm trying to write the ioctl() based equivalent of what I've start= ed > > > > but I can't figure out how to start tracing by forking a new child. > > > >=20 > > > > Here's how I do it on Linux: > > > > fork() > > > > child: call kill(getpid(), SIGSTOP) and wait for the parent to res= ume. > > > > parent: wait for the child, set up tracing options and start traci= ng. > > > >=20 > > > > I can directly use execve() so the child will stop too but I'm writ= ing a > > > > library and for its unit tests I need to use the SIGSTOP method bec= ause > > > > I won't do any exec'ing. > > > >=20 > > > > I tried to do the same with ioctl(), it works most of the time but = it > > > > hangs every now and then at PIOCWAIT. I'm inclined to think there's= a > > > > race condition but I couldn't figure out why. > > > >=20 > > > > The code is here: http://alip.github.com/code/piocstatus-2.c > > > >=20 > > > > Fwiw this is about a library called > > > > pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to wri= te. > > > > Its aim is to be a lightweight portable tracing library with multip= le > > > > backends (like procfs and ptrace etc.) I think this could prove use= ful > > > > for many people who need to do tracing and doesn't want to bother w= ith > > > > platform specific details. > > >=20 > > > I see. You could try this patch. It requires HEAD or recent RELENG_8 > > > to be applicable. I added PL_EVENT_SCE/SCX to PT_LWPINFO for i386 and > > > amd64. Please note that I did not tested it, only booted the kernel to > > > make sure that it does not break too ugly. > > >=20 > > > diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c > > > index f3dba94..f97f875 100644 > > > >=20 > > Looks great, I could only test it basically but it seems to work fine. > > If this is merged, truss can make use of this too. > >=20 > > Another question is how hard is it to implement PL_EVENT_EXEC? > > This could be useful for truss as it updates the execution type of the > > process after successful execve() calls afaict. >=20 > Is this needed ? The question is not rhetorical, I am trying to > understand what prevents use of PT_TO_SCE and checking the syscall > number ? You would screen for SYS_execve or SYS_fexecve and > reset the debugger state on SIGTRAP that is supplied to the debugger > before first instruction of new image is executed. >=20 Not really needed, just cleaner imo. As system call numbers may be different for different execution types and you need to look it up from a table using a string as argument which is slow. > Can you, please, extract and provide me with the code you used to test > the PL_EVENT_SCE/SCX patch ? Sure, the code is below. It doesn't work though (Sorry to tell you it was working fine in my first post, too much vodka makes me see things differently as it seems). The PT_LWPINFO request returns PL_EVENT_SIGNAL in both cases. #include #include #include #include #include #include #include int main(void) { int status; pid_t pid; struct ptrace_lwpinfo lwpinfo; if ((pid =3D fork()) < 0) { perror("fork"); return 1; } else if (!pid) { /* child */ if (ptrace(PT_TRACE_ME, 0, NULL, 0) < 0) { perror("PT_TRACE_ME"); _exit(1); } kill(getpid(), SIGSTOP); getpid(); } else { /* parent */ waitpid(pid, &status, 0); assert(WIFSTOPPED(status)); assert(WSTOPSIG(status) =3D=3D SIGSTOP); if (ptrace(PT_TO_SCE, pid, (caddr_t)1, 0) < 0) { perror("PT_TO_SCE"); ptrace(PT_KILL, pid, NULL, 0); return 2; } waitpid(pid, &status, 0); assert(WIFSTOPPED(status)); assert(WSTOPSIG(status) =3D=3D SIGTRAP); if (ptrace(PT_LWPINFO, pid, (caddr_t)&lwpinfo, sizeof lwpinfo) < 0) { perror("PT_LWPINFO"); ptrace(PT_KILL, pid, NULL, 0); return 3; } printf("event =3D %d\n", lwpinfo.pl_event); assert(lwpinfo.pl_event =3D=3D PL_EVENT_SCE); if (ptrace(PT_TO_SCX, pid, (caddr_t)1, 0) < 0) { perror("PT_TO_SCX"); ptrace(PT_KILL, pid, NULL, 0); return 2; } waitpid(pid, &status, 0); assert(WIFSTOPPED(status)); assert(WSTOPSIG(status) =3D=3D SIGTRAP); if (ptrace(PT_LWPINFO, pid, (caddr_t)&lwpinfo, sizeof lwpinfo) < 0) { perror("PT_LWPINFO"); ptrace(PT_KILL, pid, NULL, 0); return 3; } printf("event =3D %d\n", lwpinfo.pl_event); assert(lwpinfo.pl_event =3D=3D PL_EVENT_SCX); ptrace(PT_CONTINUE, pid, (caddr_t)1, 0); return 0; } } --=20 Regards, Ali Polatel --w2JjAQZceEVGylhD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvpMtQACgkQQU4yORhF8iBX+QCeIva6aIHa4Ne/x3h0XQDodTy+ IckAnjAcWdsZaDJ1BmiGrg3V5JMo9hpW =RhTe -----END PGP SIGNATURE----- --w2JjAQZceEVGylhD-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 12:06:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46951106568D for ; Tue, 11 May 2010 12:06:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 58FFA8FC13 for ; Tue, 11 May 2010 12:06:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4BC6aNX028102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 15:06:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4BC6MkJ014438; Tue, 11 May 2010 15:06:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4BC6MR9014437; Tue, 11 May 2010 15:06:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 May 2010 15:06:22 +0300 From: Kostik Belousov To: Ali Polatel Message-ID: <20100511120622.GU83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> <20100510164847.GF8186@harikalardiyari> <20100510170947.GP83316@deviant.kiev.zoral.com.ua> <20100511103500.GH8186@harikalardiyari> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V4yrq4dHtCqH+JvC" Content-Disposition: inline In-Reply-To: <20100511103500.GH8186@harikalardiyari> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 11 May 2010 12:06:29 -0000 --V4yrq4dHtCqH+JvC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 01:35:00PM +0300, Ali Polatel wrote: > Kostik Belousov yazm??: > > On Mon, May 10, 2010 at 07:48:47PM +0300, Ali Polatel wrote: > > > Kostik Belousov yazm??: > > > > On Sun, May 09, 2010 at 09:28:51PM +0300, Ali Polatel wrote: > > > > > Kostik Belousov yazm??: > > > > > > On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote: > > > > > > > Kostik Belousov yazm??: > > > > > > > > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: > > > > > > > > > Does FreeBSD's ptrace have a way to tell the difference b= etween normal > > > > > > > > > traps and those caused by a system call? > > > > > > > > >=20 > > > > > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGO= OD option to the > > > > > > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel s= et bit 7 in the > > > > > > > > > syscall number when delivering system call traps, > > > > > > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > > > > > > >=20 > > > > > > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO r= equest looks > > > > > > > > > related but can't be sure. > > > > > > > > >=20 > > > > > > > > > ?: http://linux.die.net/man/2/ptrace > > > > > > > >=20 > > > > > > > > There is already procfs(5)-based interface to get a reason = for stop. > > > > > > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > > > > > > >=20 > > > > > > > > The interface can be lifted to ptrace(2), but I think using= the capacity > > > > > > > > of procfs is not wrong there. > > > > > > >=20 > > > > > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn= 't seem to > > > > > > > work, there's not much documentation about it either so I fig= ured I'll > > > > > > > just ask. > > > > > > >=20 > > > > > > > The code is here: http://alip.github.com/code/piocstatus.c > > > > > > >=20 > > > > > > > The traced child is stopped at the beginning of a system call= . I await > > > > > > > that the PIOCSTATUS request sets ps.why to S_SCE but it's alw= ays zero. > > > > > > > Can you help me figure out what I'm doing wrong? :) > > > > > >=20 > > > > > > Apparently I missed the fact that S_PT_SCE and S_SCE are differ= ent > > > > > > flags. It seems you have to use procfs stop events (PIOCBIS) and > > > > > > procfs-based loop to get p_step set to 1. > > > > >=20 > > > > > So I can't use ptrace() together with ioctl() based tracing. > > > > > Fair enough... > > > > >=20 > > > > > I'm trying to write the ioctl() based equivalent of what I've sta= rted > > > > > but I can't figure out how to start tracing by forking a new chil= d. > > > > >=20 > > > > > Here's how I do it on Linux: > > > > > fork() > > > > > child: call kill(getpid(), SIGSTOP) and wait for the parent to r= esume. > > > > > parent: wait for the child, set up tracing options and start tra= cing. > > > > >=20 > > > > > I can directly use execve() so the child will stop too but I'm wr= iting a > > > > > library and for its unit tests I need to use the SIGSTOP method b= ecause > > > > > I won't do any exec'ing. > > > > >=20 > > > > > I tried to do the same with ioctl(), it works most of the time bu= t it > > > > > hangs every now and then at PIOCWAIT. I'm inclined to think there= 's a > > > > > race condition but I couldn't figure out why. > > > > >=20 > > > > > The code is here: http://alip.github.com/code/piocstatus-2.c > > > > >=20 > > > > > Fwiw this is about a library called > > > > > pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to w= rite. > > > > > Its aim is to be a lightweight portable tracing library with mult= iple > > > > > backends (like procfs and ptrace etc.) I think this could prove u= seful > > > > > for many people who need to do tracing and doesn't want to bother= with > > > > > platform specific details. > > > >=20 > > > > I see. You could try this patch. It requires HEAD or recent RELENG_8 > > > > to be applicable. I added PL_EVENT_SCE/SCX to PT_LWPINFO for i386 a= nd > > > > amd64. Please note that I did not tested it, only booted the kernel= to > > > > make sure that it does not break too ugly. > > > >=20 > > > > diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c > > > > index f3dba94..f97f875 100644 > > > > > >=20 > > > Looks great, I could only test it basically but it seems to work fine. > > > If this is merged, truss can make use of this too. > > >=20 > > > Another question is how hard is it to implement PL_EVENT_EXEC? > > > This could be useful for truss as it updates the execution type of the > > > process after successful execve() calls afaict. > >=20 > > Is this needed ? The question is not rhetorical, I am trying to > > understand what prevents use of PT_TO_SCE and checking the syscall > > number ? You would screen for SYS_execve or SYS_fexecve and > > reset the debugger state on SIGTRAP that is supplied to the debugger > > before first instruction of new image is executed. > >=20 >=20 > Not really needed, just cleaner imo. As system call numbers may be > different for different execution types and you need to look it up from > a table using a string as argument which is slow. >=20 > > Can you, please, extract and provide me with the code you used to test > > the PL_EVENT_SCE/SCX patch ? >=20 > Sure, the code is below. It doesn't work though (Sorry to tell you it > was working fine in my first post, too much vodka makes me see things > differently as it seems). The PT_LWPINFO request returns > PL_EVENT_SIGNAL in both cases. Yes, this is a relief, since I realized that syscall enter/leave is reported using SIGTRAP. I have to move the events to flags. Also, original patch missed SCE on i386. Below is the updated change. diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index f3dba94..f97f875 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -911,6 +911,7 @@ syscall(struct trapframe *frame) if (p->p_flag & P_TRACED) { PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); } error =3D fetch_syscall_args(td, &sa); @@ -965,6 +966,11 @@ syscall(struct trapframe *frame) #endif } retval: + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -1007,12 +1013,21 @@ syscall(struct trapframe *frame) ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } /* * This works because errno is findable through the * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa.code); - PTRACESTOP_SC(p, td, S_PT_SCX); + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCX; + PROC_UNLOCK(p); + } } diff --git a/sys/amd64/ia32/ia32_syscall.c b/sys/amd64/ia32/ia32_syscall.c index aa1ae6c..300d1f6 100644 --- a/sys/amd64/ia32/ia32_syscall.c +++ b/sys/amd64/ia32/ia32_syscall.c @@ -186,6 +186,7 @@ ia32_syscall(struct trapframe *frame) if (p->p_flag & P_TRACED) { PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); } error =3D fetch_ia32_syscall_args(td, &sa); @@ -218,6 +219,11 @@ ia32_syscall(struct trapframe *frame) td->td_errno =3D error; } retval: + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -259,14 +265,23 @@ ia32_syscall(struct trapframe *frame) ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } /* * This works because errno is findable through the * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa.code); -=20 PTRACESTOP_SC(p, td, S_PT_SCX); + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCX; + PROC_UNLOCK(p); + } } =20 =20 diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c index a11daa6..44c8585 100644 --- a/sys/i386/i386/trap.c +++ b/sys/i386/i386/trap.c @@ -1074,6 +1074,7 @@ syscall(struct trapframe *frame) if (p->p_flag & P_TRACED) { PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); } error =3D fetch_syscall_args(td, &sa); @@ -1128,6 +1129,11 @@ syscall(struct trapframe *frame) #endif } retval: + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -1170,13 +1176,22 @@ syscall(struct trapframe *frame) ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } /* * This works because errno is findable through the * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa.code); - PTRACESTOP_SC(p, td, S_PT_SCX); + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCX; + PROC_UNLOCK(p); + } } =20 diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index d8cc4f0..bc0dd24 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -1105,9 +1105,11 @@ kern_ptrace(struct thread *td, int req, pid_t pid, v= oid *addr, int data) pl->pl_lwpid =3D td2->td_tid; if (td2->td_dbgflags & TDB_XSIG) pl->pl_event =3D PL_EVENT_SIGNAL; - else - pl->pl_event =3D 0; pl->pl_flags =3D 0; + if (td2->td_dbgflags & TDB_SCE) + pl->pl_flags |=3D PL_FLAG_SCE; + else if (td2->td_dbgflags & TDB_SCX) + pl->pl_flags |=3D PL_FLAG_SCX; pl->pl_sigmask =3D td2->td_sigmask; pl->pl_siglist =3D td2->td_siglist; break; diff --git a/sys/sys/proc.h b/sys/sys/proc.h index e32e494..9457ad1 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -364,6 +364,8 @@ do { \ #define TDB_SUSPEND 0x00000001 /* Thread is suspended by debugger */ #define TDB_XSIG 0x00000002 /* Thread is exchanging signal under trace */ #define TDB_USERWR 0x00000004 /* Debugger modified memory or registers */ +#define TDB_SCE 0x00000008 /* Thread performs syscall enter */ +#define TDB_SCX 0x00000010 /* Thread performs syscall exit */ =20 /* * "Private" flags kept in td_pflags: diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h index b30447c..8be0cae 100644 --- a/sys/sys/ptrace.h +++ b/sys/sys/ptrace.h @@ -99,6 +99,8 @@ struct ptrace_lwpinfo { int pl_flags; /* LWP flags. */ #define PL_FLAG_SA 0x01 /* M:N thread */ #define PL_FLAG_BOUND 0x02 /* M:N bound thread */ +#define PL_FLAG_SCE 0x04 /* syscall enter point */ +#define PL_FLAG_SCX 0x08 /* syscall leave point */ sigset_t pl_sigmask; /* LWP signal mask */ sigset_t pl_siglist; /* LWP pending signal */ }; --V4yrq4dHtCqH+JvC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvpSD4ACgkQC3+MBN1Mb4jdNQCdFJ07HNA1nRkHruSj/y2Lu0Yk thkAoOizHMOOjouhN7HOJBItzJpVqcrL =ahNQ -----END PGP SIGNATURE----- --V4yrq4dHtCqH+JvC-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 15:58:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC0A5106564A for ; Tue, 11 May 2010 15:58:40 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D02E8FC12 for ; Tue, 11 May 2010 15:58:40 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.ntu-kpi.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OBrqx-0004Ua-9T; Tue, 11 May 2010 18:58:39 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 811011CC44; Tue, 11 May 2010 18:58:39 +0300 (EEST) Date: Tue, 11 May 2010 18:58:39 +0300 From: Andrey Simonenko To: Evan Geller Message-ID: <20100511155839.GA90132@pm513-1.comsys.ntu-kpi.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Invalid-HELO: Host impersonating [comsys.ntu-kpi.kiev.ua] X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 06-Jan-2007 23:14:37) X-Date: 2010-05-11 18:58:39 X-Connected-IP: 10.18.52.101:28058 X-Message-Linecount: 34 X-Body-Linecount: 19 X-Message-Size: 1819 X-Body-Size: 1152 Cc: freebsd-hackers@freebsd.org Subject: Re: Recursion in the UVA 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, 11 May 2010 15:58:40 -0000 On Mon, May 10, 2010 at 11:42:26AM -0700, Evan Geller wrote: > I'm a bit confused how recursion in the UVA works. vm_map_entries are > allocated from a vm_map_entry zone, but if the vm_map_entry slabs are > full and it needs to allocate a vm_map_entry to satisfy the mapping, > there would seem to be a starvation. I also see a uk_recurse field per There are two types of UMA zones for vm_map_entry structures. One is used for system maps (kmapentzone) and another one is used for regular maps (mapentzone). When kmapentzone is created it got a flag that force it to get new items only from items it owns. Some items are preallocated for kmapentzone on startup and later kmapentzone gets own object, from which it will take new items. So, all items for kmapentzone will be taken from an object that was already inserted in kernel_map. For the mapentzone (for regular vm_map_entry structures) items are taken as usual and new vm_map_entry structures can be created for these allocations, but required extra vm_map_entry will be allocated from kmapentzone (since it will belong to some system map) that use own object with own pages for its items. From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 17:11:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20C31065673 for ; Tue, 11 May 2010 17:11:26 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6780F8FC16 for ; Tue, 11 May 2010 17:11:26 +0000 (UTC) Received: from baby-jane.lamaiziere.net (unknown [192.168.1.10]) by smtp.lamaiziere.net (Postfix) with ESMTP id D6D3C63307D; Tue, 11 May 2010 19:11:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 6F52A2CEE1D; Tue, 11 May 2010 19:11:41 +0200 (CEST) Date: Tue, 11 May 2010 19:11:40 +0200 From: Patrick Lamaiziere To: Sam Leffler Message-ID: <20100511191140.2111cc70@davenulle.org> In-Reply-To: References: <4BE46650.7010008@bluezbox.com> <20100510001637.2a564cd5@davenulle.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: hifn(4) DMA fix for review 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, 11 May 2010 17:11:26 -0000 Le Mon, 10 May 2010 08:26:08 -0700, Sam Leffler a écrit : Hello, > > I noticed several things in hifn, if you want to look: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130286 > > > > IMHO some locks are missing in the use of sc->sc_sessions (the array > > containing the sessions) : in hifn_newsession(), if there is no > > space left in sc->sc_sessions, a new array is allocated and the > > sessions are copied to it. Unfortunaly, sc->sc_sessions is used in > > hifn_process without any lock and we use some pointers on the array > > (my patch should > > addresses this if I remember...). > > Isn't this just the glx locking? (no offense intended) I've said > before I think we to move session management up into the crypto > layer since it's implemented in many drivers (usually w/ c&p of the > same code as you noted here sometimes a bit different). Yes, the code comes mostly from padlock and glxsb. glxsb and padlock use a TAILQ to store the sessions instead of an array. It is better when we want to add or remove a session but we have to search the session each time when processing the operation. In hifn, the session id (sid) is directly the index so it should be more efficient. I'm not sure if this is a concern or not. Regards. From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 19:23:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D42391065676; Tue, 11 May 2010 19:23:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B00A28FC1A; Tue, 11 May 2010 19:23:41 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4A09A46B45; Tue, 11 May 2010 15:23:41 -0400 (EDT) Date: Tue, 11 May 2010 20:23:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Lev Serebryakov In-Reply-To: <1127023465.20100510115708@serebryakov.spb.ru> Message-ID: References: <1127023465.20100510115708@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: How to get stack bounds of current process? 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, 11 May 2010 19:23:41 -0000 On Mon, 10 May 2010, Lev Serebryakov wrote: > I'm proting some application from Linux, which discover its stack bounds by > reading and pasing "/proc/self/maps". FreeBSD have "/prov/curproc/map", but > I can not find how to determine which record is for stack (I've looked into > implementation of proc_fs, but it doesn't contain any specail processing for > process stack). > > How could I determine stack bounds of current process on FreeBSD 7/8/9? The "procstat -v" command in 8.x and 9.x will give this information based on sysctls; we're about to integrate a libprocstat(3) library which will provide a public API for this information. I'd agree with Kostik that you should think carefully about whether the application really needs this information :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 19:50:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5841065686; Tue, 11 May 2010 19:50:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9889B8FC17; Tue, 11 May 2010 19:50:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4BJoMQE067293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 22:50:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4BJo9bA049265; Tue, 11 May 2010 22:50:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4BJo8nL049264; Tue, 11 May 2010 22:50:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 May 2010 22:50:08 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20100511195008.GX83316@deviant.kiev.zoral.com.ua> References: <1127023465.20100510115708@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MTFjS3R2zZZVGaSB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Lev Serebryakov Subject: Re: How to get stack bounds of current process? 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, 11 May 2010 19:50:13 -0000 --MTFjS3R2zZZVGaSB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 11, 2010 at 08:23:41PM +0100, Robert Watson wrote: >=20 > On Mon, 10 May 2010, Lev Serebryakov wrote: >=20 > > I'm proting some application from Linux, which discover its stack bound= s=20 > > by reading and pasing "/proc/self/maps". FreeBSD have=20 > >"/prov/curproc/map", but I can not find how to determine which record is= =20 > >for stack (I've looked into implementation of proc_fs, but it doesn't=20 > >contain any specail processing for process stack). > > > > How could I determine stack bounds of current process on FreeBSD 7/8/9? >=20 > The "procstat -v" command in 8.x and 9.x will give this information based= =20 > on sysctls; we're about to integrate a libprocstat(3) library which will= =20 > provide a public API for this information. I'd agree with Kostik that yo= u=20 > should think carefully about whether the application really needs this=20 > information :-). Unfortunately, it is not that simple. How to guess which vm_map_entries are from the stack ? To complicate the issue, the stack is usually fragmented, i.e. continuous VA area is covered by several adjanced entries. The answer "look at the kern.ps_strings" is bad as well, since it gives wrong answer e.g. for ia32 binary on amd64. Idea to look at the highest mapped address and then descend might be safest, but as I already pointed out, libthr.so clamps the main stack to keep its size the same as for non-main threads. And this is ignoring issues of non-main thread stacks, as well as signal altstacks. As I said, there is no good answer to the question, and better strategy is to understand why application need this. --MTFjS3R2zZZVGaSB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvptPAACgkQC3+MBN1Mb4hMcgCgwPxd4vHdSAxUA0Pp2viMVTDv U0MAoJ4u91c1JUUsNh1/NGV0pJ4CaKiH =Gomc -----END PGP SIGNATURE----- --MTFjS3R2zZZVGaSB-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 20:03:04 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D374106564A for ; Tue, 11 May 2010 20:03:04 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9948FC08 for ; Tue, 11 May 2010 20:03:03 +0000 (UTC) Received: by vws12 with SMTP id 12so999397vws.13 for ; Tue, 11 May 2010 13:03:02 -0700 (PDT) Received: by 10.220.128.202 with SMTP id l10mr1202468vcs.57.1273606591167; Tue, 11 May 2010 12:36:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.31 with HTTP; Tue, 11 May 2010 12:36:11 -0700 (PDT) From: Eitan Adler Date: Tue, 11 May 2010 22:36:11 +0300 Message-ID: To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: proposed change to style(9): require yoda style if statements 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, 11 May 2010 20:03:04 -0000 My proposal is simple: require that any if statement that compares a constant to a mutable variable be written as if (constant == variable) instead of if (variable == constant) this prevents an extremely common programming error if (variable = constant) While this is almost always found in testing sometimes thing can slip through and writing it using the former method will generate a compiler warning. From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 20:33:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2DD4106564A for ; Tue, 11 May 2010 20:33:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5579A8FC15 for ; Tue, 11 May 2010 20:33:28 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-053-135.pools.arcor-ip.net [88.66.53.135]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MZ776-1NtIIU3spo-00Ln8a; Tue, 11 May 2010 22:33:27 +0200 Received: (qmail 9267 invoked from network); 11 May 2010 20:33:26 -0000 Received: from f8x64.laiers.local (192.168.4.188) by ns1.laiers.local with SMTP; 11 May 2010 20:33:26 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Tue, 11 May 2010 22:33:24 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201005112233.24473.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19WfJ9N6/co/WsWZkUZHnyPXXHLIUylS8yGm9A 8dfvd01dV3Ngm+5qnHtHZRANr63R2BDjnjkQM9K2+rQV6QKYM+ e6/GKv8+vr9waZ6Az/qfA== Cc: Eitan Adler Subject: Re: proposed change to style(9): require yoda style if statements 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, 11 May 2010 20:33:28 -0000 On Tuesday 11 May 2010 21:36:11 Eitan Adler wrote: > My proposal is simple: > require that any if statement that compares a constant to a mutable > variable be written as > if (constant == variable) > instead of > if (variable == constant) > > this prevents an extremely common programming error > if (variable = constant) > > While this is almost always found in testing sometimes thing can slip > through and writing it using the former method will generate a compiler > warning. With proper -W flags, "if (var = const)" also yields a warning: warning: suggest parentheses around assignment used as truth value and style already tells you to avoid unnecessary parentheses. Chaning style(9) in such a fundamental way almost, always isn't a good idea. It's simply unrealistic to change all current code to comply and the difference between old and new code will just add to the confusion. Best, Max From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 20:59:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9FC1106567C for ; Tue, 11 May 2010 20:59:01 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 77ED28FC1B for ; Tue, 11 May 2010 20:59:01 +0000 (UTC) Received: by vws12 with SMTP id 12so1070531vws.13 for ; Tue, 11 May 2010 13:59:00 -0700 (PDT) Received: by 10.220.123.5 with SMTP id n5mr506529vcr.249.1273610195450; Tue, 11 May 2010 13:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.31 with HTTP; Tue, 11 May 2010 13:36:15 -0700 (PDT) In-Reply-To: <201005112233.24473.max@love2party.net> References: <201005112233.24473.max@love2party.net> From: Eitan Adler Date: Tue, 11 May 2010 23:36:15 +0300 Message-ID: To: Max Laier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if statements 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, 11 May 2010 20:59:01 -0000 > With proper -W flags, "if (var =3D const)" also yields a warning: > > =C2=A0warning: suggest parentheses around assignment used as truth value > > Chaning style(9) in such a fundamental way almost, always isn't a good id= ea. > It's simply unrealistic to change all current code to comply and the > difference between old and new code will just add to the confusion. Per Julian Elischer We might suggest it rather than mandate it. Also this method is compiler agnostic and generates a stronger warning (an error rather than a warning) From owner-freebsd-hackers@FreeBSD.ORG Tue May 11 21:39:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49783106564A for ; Tue, 11 May 2010 21:39:27 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id BC7128FC17 for ; Tue, 11 May 2010 21:39:26 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so148958fgb.13 for ; Tue, 11 May 2010 14:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=cjOxCkdkxARWkktbe5YjDbdQNHHOmAxYNAhjwtAWJL4=; b=RsB+krjW2+mOpdNOqCDg9Ug4ALoYXEqFunrdWn2hlGceu5tKY2Ak2RsLt7N3sXT0R4 MtJJ47tefB4rlsCLu4sqG3CTQJQYoNLRga59SJWWwx9butrzJ0chAALVfaXiNKpqDkCi EAGZMX0C8+NbFGpZYi/JipgjDZgYuNX8o5Q3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WpiQ8o0n59au0PA91ymjthhjB6eB/LXhhsKoqTvaRGGYmR3VDDk060Z3mpN+w7bZLf nVa/QtkTnHamPANAtzbCECoAFnjv5u+ng0ol5zVmjJz1mFj9tfdZ7+7WITfazA67E98M 73cqh0qLBo0bO/QitkSD/hU7BkMhypp4QMEo4= MIME-Version: 1.0 Received: by 10.223.24.85 with SMTP id u21mr7070153fab.8.1273612458818; Tue, 11 May 2010 14:14:18 -0700 (PDT) Sender: shteryana@gmail.com Received: by 10.223.126.138 with HTTP; Tue, 11 May 2010 14:14:18 -0700 (PDT) In-Reply-To: References: <201005112233.24473.max@love2party.net> Date: Wed, 12 May 2010 00:14:18 +0300 X-Google-Sender-Auth: LLG7wGKpnxpRnqkvZkJhZ7b21BI Message-ID: From: Shteryana Shopova To: Eitan Adler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Max Laier , freebsd-hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if statements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:39:27 -0000 In my humble opinion, With proper -W flags (i.e. -Wall -Werror), the compilation will fail on "if (var =3D const)" also yoda statements of the kind if (constant =3D=3D variable) obfuscate code and make it more difficult to read, definately not a good idea IMHO, added the confusion between old and new code that Max mentioned. cheers, Shteryana On Tue, May 11, 2010 at 11:36 PM, Eitan Adler wrote: >> With proper -W flags, "if (var =3D const)" also yields a warning: >> >> =C2=A0warning: suggest parentheses around assignment used as truth value >> >> Chaning style(9) in such a fundamental way almost, always isn't a good i= dea. >> It's simply unrealistic to change all current code to comply and the >> difference between old and new code will just add to the confusion. > > Per Julian Elischer > We might suggest it rather than mandate it. > Also this method is compiler agnostic and generates a stronger warning > (an error rather than a warning) > _______________________________________________ > 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 Wed May 12 07:20:33 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEF81106564A for ; Wed, 12 May 2010 07:20:33 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 9257D8FC12 for ; Wed, 12 May 2010 07:20:33 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [188.46.113.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9FEC68A1D03; Wed, 12 May 2010 09:03:43 +0200 (CEST) Message-ID: <4BEA52CB.8080407@bsdforen.de> Date: Wed, 12 May 2010 09:03:39 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eitan Adler References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if statements 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, 12 May 2010 07:20:33 -0000 On 11/05/2010 21:36, Eitan Adler wrote: > My proposal is simple: > require that any if statement that compares a constant to a mutable variable > be written as > if (constant == variable) > instead of > if (variable == constant) > > this prevents an extremely common programming error > if (variable = constant) > > While this is almost always found in testing sometimes thing can slip > through and writing it using the former method will generate a compiler > warning. Is this suggestion due to the discussions around yoda-style in the comments of: http://www.globalnerdy.com/2010/05/09/new-programming-jargon/ I think the pro-yoda faction actually has more convincing arguments, though I never considered using yoda-style myself. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 08:01:47 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4D2C1065677 for ; Wed, 12 May 2010 08:01:47 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 830C28FC18 for ; Wed, 12 May 2010 08:01:47 +0000 (UTC) Received: by vws1 with SMTP id 1so446518vws.13 for ; Wed, 12 May 2010 01:01:46 -0700 (PDT) Received: by 10.220.127.81 with SMTP id f17mr5345214vcs.13.1273651306413; Wed, 12 May 2010 01:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.31 with HTTP; Wed, 12 May 2010 01:01:26 -0700 (PDT) From: Eitan Adler Date: Wed, 12 May 2010 11:01:26 +0300 Message-ID: To: hackers@freebsd.org Content-Type: multipart/mixed; boundary=0016e68e8ba5afbeff0486610ddd Cc: Subject: adding "check option to md5(1) [was: md5(1) and cal(1) on -questions] 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, 12 May 2010 08:01:47 -0000 --0016e68e8ba5afbeff0486610ddd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > D> 2. Why doesn't md5(1) have a "check" option? =C2=A0Seems to me requiri= ng a > D> manual inspection is error-prone at best, and makes scripting > D> unecessarily complicated. Would something like the attached patch be good? It adds a -c option for a string to check against. It prints "[failed]" if the string does not match the files md5 unless in -q mode. It also returns 2 to indicate md5 match failure for use in scripts. --0016e68e8ba5afbeff0486610ddd Content-Type: application/octet-stream; name="md5-check.patch" Content-Disposition: attachment; filename="md5-check.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9345t3k0 SW5kZXg6IG1kNS4xCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG1kNS4xCShyZXZpc2lvbiAyMDc0MzMpCisrKyBt ZDUuMQkod29ya2luZyBjb3B5KQpAQCAtNzMsNiArNzMsOCBAQAogVGhlIGhleGFkZWNpbWFsIGNo ZWNrc3VtIG9mIGVhY2ggZmlsZSBsaXN0ZWQgb24gdGhlIGNvbW1hbmQgbGluZSBpcyBwcmludGVk CiBhZnRlciB0aGUgb3B0aW9ucyBhcmUgcHJvY2Vzc2VkLgogLkJsIC10YWcgLXdpZHRoIGluZGVu dAorLkl0IEZsIGMgQXIgc3RyaW5nCitDb21wYXJlIGZpbGVzIHRvIHRoaXMgbWQ1IHN0cmluZwog Lkl0IEZsIHMgQXIgc3RyaW5nCiBQcmludCBhIGNoZWNrc3VtIG9mIHRoZSBnaXZlbgogLkFyIHN0 cmluZyAuCkBAIC0xMDEsNyArMTAzLDggQEAKIGFuZAogLk5tIHJtZDE2MAogdXRpbGl0aWVzIGV4 aXQgMCBvbiBzdWNjZXNzLAotYW5kIDEgaWYgYXQgbGVhc3Qgb25lIG9mIHRoZSBpbnB1dCBmaWxl cyBjb3VsZCBub3QgYmUgcmVhZC4KKzEgaWYgYXQgbGVhc3Qgb25lIG9mIHRoZSBpbnB1dCBmaWxl cyBjb3VsZCBub3QgYmUgcmVhZCwKK2FuZCAyIGlmIGF0IGxlYXN0IG9uZSBmaWxlIGRvZXMgbm90 IGhhdmUgdGhlIHNhbWUgaGFzaCBhcyB0aGUgLWMgb3B0aW9uLgogLlNoIFNFRSBBTFNPCiAuWHIg Y2tzdW0gMSAsCiAuWHIgbWQ1IDMgLApJbmRleDogbWQ1LmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbWQ1LmMJ KHJldmlzaW9uIDIwNzQzMykKKysrIG1kNS5jCSh3b3JraW5nIGNvcHkpCkBAIC00NCw2ICs0NCw4 IEBACiBpbnQgcWZsYWc7CiBpbnQgcmZsYWc7CiBpbnQgc2ZsYWc7Cit1bnNpZ25lZCBjaGFyKiBj aGVja0FnYWluc3Q7CitpbnQJY2hlY2tzRmFpbGVkOwogCiB0eXBlZGVmIHZvaWQgKERJR0VTVF9J bml0KSh2b2lkICopOwogdHlwZWRlZiB2b2lkIChESUdFU1RfVXBkYXRlKSh2b2lkICosIGNvbnN0 IHVuc2lnbmVkIGNoYXIgKiwgc2l6ZV90KTsKQEAgLTEzOCw4ICsxNDAsMTMgQEAKICAJCWRpZ2Vz dCA9IDA7CiAKIAlmYWlsZWQgPSAwOwotCXdoaWxlICgoY2ggPSBnZXRvcHQoYXJnYywgYXJndiwg InBxcnM6dHgiKSkgIT0gLTEpCisJY2hlY2tBZ2FpbnN0ID0gTlVMTDsKKwljaGVja3NGYWlsZWQg PSAwOworCXdoaWxlICgoY2ggPSBnZXRvcHQoYXJnYywgYXJndiwgImM6cHFyczp0eCIpKSAhPSAt MSkKIAkJc3dpdGNoIChjaCkgeworCQljYXNlICdjJzoKKwkJCWNoZWNrQWdhaW5zdCA9IG9wdGFy ZzsKKwkJCWJyZWFrOwogCQljYXNlICdwJzoKIAkJCU1ERmlsdGVyKCZBbGdvcml0aG1bZGlnZXN0 XSwgMSk7CiAJCQlicmVhazsKQEAgLTE3MywxMiArMTgwLDE5IEBACiAJCQkJZmFpbGVkKys7CiAJ CQl9IGVsc2UgewogCQkJCWlmIChxZmxhZykKLQkJCQkJcHJpbnRmKCIlc1xuIiwgcCk7CisJCQkJ CXByaW50ZigiJXMiLCBwKTsKIAkJCQllbHNlIGlmIChyZmxhZykKLQkJCQkJcHJpbnRmKCIlcyAl c1xuIiwgcCwgKmFyZ3YpOworCQkJCQlwcmludGYoIiVzICVzIiwgcCwgKmFyZ3YpOwogCQkJCWVs c2UKLQkJCQkJcHJpbnRmKCIlcyAoJXMpID0gJXNcbiIsCisJCQkJCXByaW50ZigiJXMgKCVzKSA9 ICVzIiwKIAkJCQkJICAgIEFsZ29yaXRobVtkaWdlc3RdLm5hbWUsICphcmd2LCBwKTsKKwkJCQlp ZiAoY2hlY2tBZ2FpbnN0ICYmIHN0cmNtcChjaGVja0FnYWluc3QscCkpCisJCQkJeworCQkJCQlj aGVja3NGYWlsZWQrKzsKKwkJCQkJaWYgKCFxZmxhZykKKwkJCQkJCXByaW50ZigiJXMiLCJbIEZh aWxlZCBdIik7CisJCQkJfQorCQkJCXByaW50ZigiXG4iKTsKIAkJCX0KIAkJfSB3aGlsZSAoKisr YXJndik7CiAJfSBlbHNlIGlmICghc2ZsYWcgJiYgKG9wdGluZCA9PSAxIHx8IHFmbGFnIHx8IHJm bGFnKSkKQEAgLTE4Niw2ICsyMDAsOCBAQAogCiAJaWYgKGZhaWxlZCAhPSAwKQogCQlyZXR1cm4g KDEpOworCWlmIChjaGVja3NGYWlsZWQgIT0gMCkKKwkJcmV0dXJuICgyKTsKIAogCXJldHVybiAo MCk7CiB9CkBAIC0xOTgsMTIgKzIxNCwyMCBAQAogCXNpemVfdCBsZW4gPSBzdHJsZW4oc3RyaW5n KTsKIAljaGFyIGJ1ZltIRVhfRElHRVNUX0xFTkdUSF07CiAKKwlhbGctPkRhdGEoc3RyaW5nLGxl bixidWYpOwogCWlmIChxZmxhZykKLQkJcHJpbnRmKCIlc1xuIiwgYWxnLT5EYXRhKHN0cmluZywg bGVuLCBidWYpKTsKKwkJcHJpbnRmKCIlcyIsIGJ1Zik7CiAJZWxzZSBpZiAocmZsYWcpCi0JCXBy aW50ZigiJXMgXCIlc1wiXG4iLCBhbGctPkRhdGEoc3RyaW5nLCBsZW4sIGJ1ZiksIHN0cmluZyk7 CisJCXByaW50ZigiJXMgXCIlc1wiIiwgYnVmLCBzdHJpbmcpOwogCWVsc2UKLQkJcHJpbnRmKCIl cyAoXCIlc1wiKSA9ICVzXG4iLCBhbGctPm5hbWUsIHN0cmluZywgYWxnLT5EYXRhKHN0cmluZywg bGVuLCBidWYpKTsKKwkJcHJpbnRmKCIlcyAoXCIlc1wiKSA9ICVzIiwgYWxnLT5uYW1lLCBzdHJp bmcsIGJ1Zik7CisJaWYgKGNoZWNrQWdhaW5zdCAmJiBzdHJjbXAoYnVmLGNoZWNrQWdhaW5zdCkp CisJeworCQljaGVja3NGYWlsZWQrKzsKKwkJaWYgKCFxZmxhZykKKwkJCXByaW50ZigiJXMiLCIg WyBmYWlsZWQgXSIpOworCX0KKwlwcmludGYoIlxuIik7CiB9CiAvKgogICogTWVhc3VyZXMgdGhl IHRpbWUgdG8gZGlnZXN0IFRFU1RfQkxPQ0tfQ09VTlQgVEVTVF9CTE9DS19MRU4tYnl0ZSBibG9j a3MuCg== --0016e68e8ba5afbeff0486610ddd-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 12:45:45 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B50C3106564A for ; Wed, 12 May 2010 12:45:45 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 74C9A8FC08 for ; Wed, 12 May 2010 12:45:45 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7520B1FFC22; Wed, 12 May 2010 12:45:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A2B2C84495; Wed, 12 May 2010 14:43:36 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dominic Fandrey References: <4BEA52CB.8080407@bsdforen.de> Date: Wed, 12 May 2010 14:43:36 +0200 In-Reply-To: <4BEA52CB.8080407@bsdforen.de> (Dominic Fandrey's message of "Wed, 12 May 2010 09:03:39 +0200") Message-ID: <86zl05thmv.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if statements 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, 12 May 2010 12:45:45 -0000 Dominic Fandrey writes: > I think the pro-yoda faction actually has more convincing arguments, Which ones? Never seen any beyond the basic "helps avoid accidentally typing =3D instead of =3D=3D". It's bollocks, anyway, because a) for every (variable =3D=3D constant) comparison you have ten (variable =3D=3D variabl= e) comparisons and b) good compilers will warn about bare assignments used as conditions. The only practical effect of Yoda style is to make code harder to read. Your .sig is strangely appropriate... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 14:40:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 259CA106564A for ; Wed, 12 May 2010 14:40:00 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id D9AAC8FC21 for ; Wed, 12 May 2010 14:39:59 +0000 (UTC) Received: from mobileKamikaze.norad (vpn-cl-163-27.rz.uni-karlsruhe.de [141.3.163.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id CF4238A1CB3 for ; Wed, 12 May 2010 16:39:58 +0200 (CEST) Message-ID: <4BEABDBE.6080107@bsdforen.de> Date: Wed, 12 May 2010 16:39:58 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4BEA52CB.8080407@bsdforen.de> <86zl05thmv.fsf@ds4.des.no> In-Reply-To: <86zl05thmv.fsf@ds4.des.no> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: proposed change to style(9): require yoda style if statements 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, 12 May 2010 14:40:00 -0000 On 12/05/2010 14:43, Dag-Erling Smørgrav wrote: > Dominic Fandrey writes: >> I think the pro-yoda faction actually has more convincing arguments, > > Which ones? Never seen any beyond the basic "helps avoid accidentally > typing = instead of ==". It's bollocks, anyway, because a) for every > (variable == constant) comparison you have ten (variable == variable) > comparisons and b) good compilers will warn about bare assignments used > as conditions. > > The only practical effect of Yoda style is to make code harder to read. The convincing one applies to Java and C++: if (constant.equals(object)) instead of if (object != null && object.equals(constant)) actually looks easier to read. Though you are right about constants being pretty rare. > Your .sig is strangely appropriate... Not my invention, this is a pretty common one, used by many people on the net. I actually have no idea where it comes from. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 14:44:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A87BC1065672 for ; Wed, 12 May 2010 14:44:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6907B8FC12 for ; Wed, 12 May 2010 14:44:01 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7AF041FFC22; Wed, 12 May 2010 14:44:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 9AE1384495; Wed, 12 May 2010 16:41:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dominic Fandrey References: <4BEA52CB.8080407@bsdforen.de> <86zl05thmv.fsf@ds4.des.no> <4BEABDBE.6080107@bsdforen.de> Date: Wed, 12 May 2010 16:41:52 +0200 In-Reply-To: <4BEABDBE.6080107@bsdforen.de> (Dominic Fandrey's message of "Wed, 12 May 2010 16:39:58 +0200") Message-ID: <86sk5xtc5r.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if statements 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, 12 May 2010 14:44:01 -0000 Dominic Fandrey writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Your .sig is strangely appropriate... > Not my invention, this is a pretty common one, used by many people > on the net. I actually have no idea where it comes from. My point is that it is strangely appropriate to the topic we are discussing. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 17:53:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8F0106566B for ; Wed, 12 May 2010 17:53:41 +0000 (UTC) (envelope-from knoseeker@googlemail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id B6B948FC26 for ; Wed, 12 May 2010 17:53:40 +0000 (UTC) Received: by ywh11 with SMTP id 11so126729ywh.7 for ; Wed, 12 May 2010 10:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=lum8Fd29iD1wZTPD5duL1wVXFkFF33Hz9APrJba8hOU=; b=pYiVqSsUKXqNCYdCgz0OWz/m9xLxmjRS3Aak9hTesqMLWqIjp0VBAvj5P1KxOCB5t0 9q4EMMcAOpKgVJILiLjhhd1YxIqE+RagdkD1V2WqX++24qoL1iFnH6e8TNbqMQZJ0VJV eOxCGdiQoN/jali+GpHkhsh1AeiAKF7pimCHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pDCBWneQN5wRMi1T1xJoze7QU/47RFc+ZKNF74dCV+NosRgc9FYkW4u4lFh7Z7sbNb IvsHKHT+dKIATKDbp7h4BUWra3Pe+kh5leEGVLqFqcGUWQG3zGqDP/18kMFFuIJEugl2 +1EpTtDGOzv1egwBECyjutkBPAiMCF7MceI5Q= MIME-Version: 1.0 Received: by 10.151.28.13 with SMTP id f13mr13586220ybj.143.1273686819103; Wed, 12 May 2010 10:53:39 -0700 (PDT) Received: by 10.151.85.19 with HTTP; Wed, 12 May 2010 10:53:38 -0700 (PDT) Date: Wed, 12 May 2010 17:53:38 +0000 Message-ID: From: Knowledge Seeker To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: utimes(2): changing the birth time 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, 12 May 2010 17:53:41 -0000 Hi, Is there a way to set birth time to a value greater(newer) than the actual birth time (not in the future, but not the current time)? The man page utimes(2) says that is only possible to change to an older value. I saw a way to do this by opening a new file, coping the data, setting the other attributes, then calling utimes 2 times to set the birth and the modification time. Is there a way to change it without creating a new file? Thanks in advance. -- Knoseeker From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 18:38:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12A9D106566C for ; Wed, 12 May 2010 18:38:29 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8278FC0A for ; Wed, 12 May 2010 18:38:28 +0000 (UTC) Received: by fxm1 with SMTP id 1so440334fxm.13 for ; Wed, 12 May 2010 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=p5ut7tndTo1Ut854W1GWJFpptFr27ZVFTnZWkUlahv0=; b=qA1pNHcN6ErO53b3CLoHU21fyAknfgQiCJWzcHsjaq6idbGLcBasvRkuiOp8zcDlXo aWXP+dUDSIP5UaecxKV6seJ6oTQlNXY/VUCGNNjxznBvJjpopDwCPaaxMomAWK4cU5QU eKfDf9zeKkPeoJxYY53Z00xr1bCJENpnzdPW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=QYkvjnUFAugIHeYtVeyOczk+k+y+MH6CoYfhk6QLOlFu4Vj0YzoQaEPhJTzEI3XPnS DbKH+y5QdnjGq07yMCE7Bbl4Wa3UxpyZqxCccYhWzHL3sCUIl9mgGB3Tp9I6rnkSsA3p +qpM62uLvkES8ZA6vYplMKZbsQjFQQjlzlbbE= Received: by 10.223.72.156 with SMTP id m28mr8775145faj.26.1273689507603; Wed, 12 May 2010 11:38:27 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE5487.dip.t-dialin.net [87.174.84.135]) by mx.google.com with ESMTPS id 13sm1890314fad.7.2010.05.12.11.38.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 11:38:27 -0700 (PDT) Date: Wed, 12 May 2010 20:38:25 +0200 From: Gary Jennejohn To: Knowledge Seeker Message-ID: <20100512203825.1db158db@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: utimes(2): changing the birth time X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 18:38:29 -0000 On Wed, 12 May 2010 17:53:38 +0000 Knowledge Seeker wrote: > Hi, > Is there a way to set birth time to a value greater(newer) than the actual > birth time (not in the future, but not the current time)? > The man page utimes(2) says that is only possible to change to an older > value. > > I saw a way to do this by opening a new file, coping the data, setting the > other attributes, then calling utimes 2 times to set the birth and the > modification time. > > Is there a way to change it without creating a new file? > Not with the current code. vfs_syscalls.c:setutimes() explicitly checks that the new time is less than va_birthtime. Interestingly enough, there's code in the routine to handle what this comment in utimes(2) mentions, but it's not implemented yet. "Ideally a new system call will be added that allows the setting of all three times at once." -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 19:25:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE561065676 for ; Wed, 12 May 2010 19:25:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id 307D48FC13 for ; Wed, 12 May 2010 19:25:29 +0000 (UTC) Received: by ywh11 with SMTP id 11so186904ywh.7 for ; Wed, 12 May 2010 12:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VXUv5XFfz5wkb1hedo3ntPsKY73Z4ybBDnxQ6sbLOyw=; b=PmYROGl3Tl/eoVHqv7Ix/ttagxGDfqL2O7VX9kzIp8WNG5e2Yuw1JE5z6tBCJAZXvw GJFMCWQszB2cmupkVIhDb2Ly+rc8x4Qz5oZ8/Z6W+4jYRn4Mpqxe5zEadyyMDq1El0FE wHmXQevEzhXopl1BDCUgXqzEu2+nsMuYZTdCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=miXgDMU0HPVP9KW0iRyw/OstGO0uqtYn9VWca1A+d68dC9X+ykI43E/8ZQe2Sza/1X W8zfzS2+4TkJC0d+UnLL1KwY3O5MwrlxKySNtoOYP6ofH6VYHCNTCNEtoJWEzsAtNQEc l0wcKJzysViPws3PLXvtLCBMo7HGcHeukUF4A= MIME-Version: 1.0 Received: by 10.101.5.15 with SMTP id h15mr4993385ani.81.1273692325616; Wed, 12 May 2010 12:25:25 -0700 (PDT) Received: by 10.100.208.9 with HTTP; Wed, 12 May 2010 12:25:25 -0700 (PDT) In-Reply-To: <20100512203825.1db158db@ernst.jennejohn.org> References: <20100512203825.1db158db@ernst.jennejohn.org> Date: Wed, 12 May 2010 23:25:25 +0400 Message-ID: From: pluknet To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Knowledge Seeker Subject: Re: utimes(2): changing the birth time 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, 12 May 2010 19:25:30 -0000 On 12 May 2010 22:38, Gary Jennejohn wrote: > On Wed, 12 May 2010 17:53:38 +0000 > Knowledge Seeker wrote: > >> Hi, >> Is there a way to set birth time to a value greater(newer) than the actu= al >> birth time (not in the future, but not the current time)? >> The man page utimes(2) says that is only possible to change to an older >> value. >> >> I saw a way to do this by opening a new file, coping the data, setting t= he >> other attributes, then calling utimes 2 times to set the birth and the >> modification time. >> >> Is there a way to change it without creating a new file? >> > > Not with the current code. =A0vfs_syscalls.c:setutimes() explicitly check= s > that the new time is less than va_birthtime. > > Interestingly enough, there's code in the routine to handle what this > comment in utimes(2) mentions, but it's not implemented yet. > > "Ideally a new system call will be added that allows the setting of all > three times at once." > btw, there's a paper someone can find something interesting at. http://www.usenix.org/events/bsdcon03/tech/full_papers/mckusick/mckusick_ht= ml/ --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed May 12 21:30:43 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 693AB106566B for ; Wed, 12 May 2010 21:30:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4CF8FC1D for ; Wed, 12 May 2010 21:30:42 +0000 (UTC) Received: by qyk28 with SMTP id 28so555863qyk.27 for ; Wed, 12 May 2010 14:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=ZiGg2Kx31P3paT/mV+lnF3Jdj7d7WhnJ7kOciqy6Ws4=; b=qVI4NphdBswgLJvDg+T/bMOuZ1ne2yXz1RtxT2H3H2YsL6j2jfIgv9G+mPqfrDFdSK rHmkhrcw3mLKXJj56CDLPjIr/t2nYSynqlmBCOOQAob/nsGq2WQzUqWE9uuRmd96ImtO HQDcEvqs0M8UcawCf8iU0Pi0mnpcuNcPBhXgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=tyzXvTZ5TWAk2EjqgSeuvrN01bZjpg1n/gjkREhHHP9dBb+iVdvYuD8w4gFTt8PbsL /GIS7powcChl59Spgu10Q4VXu2mdVyUJstNckHeFFmFLXuxCOe5zUPd7fWLDa3ZxmBJ0 EmCWosNMWY1lim7dJAXjdE4VLh09DVoxK9+uA= Received: by 10.229.226.135 with SMTP id iw7mr5236619qcb.63.1273699842289; Wed, 12 May 2010 14:30:42 -0700 (PDT) Received: from [172.24.100.15] ([192.75.139.254]) by mx.google.com with ESMTPS id bv23sm228894qcb.7.2010.05.12.14.30.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 14:30:38 -0700 (PDT) From: Garrett Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 17:30:48 -0400 Message-Id: To: hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: Subject: argv offset -- doesn't make sense... 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, 12 May 2010 21:30:43 -0000 Hi Hackers, Ignoring the compiler warning (yes, I know...), why is the = offset for the argv[0] (program name) in the following program off by = one? It doesn't make sense why the fstat would work, but the printf = would fail (and in fact segfault if I remove the 1 < argc guard = statement and adjusted the offset by removing the +1). Thanks, -Garrett PS I know I'm missing all of the real error checks because I just wanted = a quick and dirty test app. # gcc -Wall -O0 -g -o test_fstat test_fstat.c test_fstat.c: In function 'main': test_fstat.c:20: warning: format '%lu' expects type 'long unsigned int', = but argument 3 has type 'off_t' # ./test_fstat ./test_fstat argc - 2, argv[0] - ./test_fstat (null) - 7118 # ./test_fstat ./test_fstat argc - 2, argv[0] - ./test_fstat ./test_fstat - -790036480 # cat test_fstat.c #include #include #include #include int main(int argc, char **argv) { if (1 < argc) { printf("argc - %d, argv[0] - %s\n", argc, *argv); int fd =3D open(*(argv+1), O_RDONLY); struct stat *sb; fstat(fd, sb); printf("%s - %ld\n", *(argv+1), (long int) sb->st_size); } return 0; }= From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 02:45:15 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 576A31065672 for ; Thu, 13 May 2010 02:45:15 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C33098FC0A for ; Thu, 13 May 2010 02:45:14 +0000 (UTC) Received: by vws1 with SMTP id 1so921880vws.13 for ; Wed, 12 May 2010 19:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=RrQRSHY+5QAiqjeGM6mpW4qylBNtD1W7JFTwhdVNmgE=; b=ieAWp+5iRyUcUI0g5rhk1nKFGJRUmdLY48QwWoNczkwTmOYIsVSrofBVkc+lP4xy1k 1PuXZNWXu+7KvYMokDRXvUq3bI6e8bU+SvWSPGIr1lGJbgY1/F0Y9pBRa0kSE5XJkvvb Yaoca5akud9aYmIs5WYadsVATrS69eGWo/mrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CxHGYWMstYD6L1lwKiheUsd2Sbsu05D2F4MD3ku05GFKG3/RO1vpFasquo/iZwElns kE/eLIT6Y6Ex3TPF3gnqhW48K2HKRFLzvBg10XjzWeBrHGObLqYrBxR9tqpgT+1KOZNK oHmcca2K9CC0HEL4VpW6YWpX13bqHkvN5zmjU= Received: by 10.220.128.136 with SMTP id k8mr6084500vcs.58.1273718713684; Wed, 12 May 2010 19:45:13 -0700 (PDT) Received: from [192.168.15.41] ([24.114.252.239]) by mx.google.com with ESMTPS id z22sm3418831vco.22.2010.05.12.19.45.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 19:45:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20100512185415.7b6d2583@bhuda.mired.org> Date: Wed, 12 May 2010 22:45:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BEE374F-6A0C-409B-943C-653BA66FCAF5@gmail.com> References: <20100512185415.7b6d2583@bhuda.mired.org> To: Mike Meyer X-Mailer: Apple Mail (2.1078) Cc: hackers@freebsd.org Subject: Re: argv offset -- doesn't make sense... 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, 13 May 2010 02:45:15 -0000 On May 12, 2010, at 6:54 PM, Mike Meyer wrote: > On Wed, 12 May 2010 17:30:48 -0400 > Garrett Cooper wrote: >=20 >> Hi Hackers, >> Ignoring the compiler warning (yes, I know...), why is the = offset for the argv[0] (program name) in the following program off by = one? It doesn't make sense why the fstat would work, but the printf = would fail (and in fact segfault if I remove the 1 < argc guard = statement and adjusted the offset by removing the +1). >> Thanks, >> -Garrett >=20 > It isn't off by one. argv is a pointer to pointers to char, so *argv > is a pointer to char, and so is *(argv+1). In the latter case, it > increments by the size of a pointer, so *(argv+1) is the same as > argv[1]. You're confusing the issue by having argv[0] and argv[1] be > copies of the same string. If you make argv[1] something_else, you > get: >=20 > bhuda% ./test_fstat something_else > argc - 2, argv[0] - ./test_fstat > something_else - 3745212532062 >=20 > Your real bug is that you never allocate the buffer you passed to > fstat. You need to declare sb without the "*", and then pass &sb to > fstat and reference sb.st_size. With what you've got, fstat will write > the stat results across whatever address is on the stack space > allocated to the pointer sb. >=20 > Removing the test and increment (which one?) will move the code > around, potentially changing the value of the pointer sb, both of > which will cause a different part of memory to be clobbered by the > call to fstat, meaning things will blow up in a different way. Yup ... as pointed out on the list elsewhere, that was my fault = by not properly allocating the storage for the pointer to the struct = stat object. Silly me for not realizing it sooner. Thanks for the help :), -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 10:26:43 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837521065670 for ; Thu, 13 May 2010 10:26:43 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 576DF8FC19 for ; Thu, 13 May 2010 10:26:43 +0000 (UTC) Received: by pwi9 with SMTP id 9so706517pwi.13 for ; Thu, 13 May 2010 03:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Nt7yIVDhCX4uJsY6SNuJ21jNCKd7JxpqX83V65NBA9I=; b=FGHohiEzw/Fw2Lhg+pvdh1BH1WKOUCDY3Meb+E3i6AIB/3fDhWrZSsi8XcwcId/4Gq DenzFCtWcF6xiYoqXkEQiHt3qKkG9QxVQ26rTXrtN9Nqe0A+qK4g81Wo4bYnl/hGIpEU qE5hG6dxhX5f6IEJEt1iGYEp2dYZpHRWTA/Rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KD5t99OqHax0Rf5kuZftZ78IGb8KM2/tO1ub01YzUiI/TK6lFZgqMwLN2CCvJmq2d9 ECfKxk8SkEU3r8ZokTr3C+oe0CJLvsYsnQmSYY/WDxYmbxAeAwRQQYG7Pp6CDe1AOGyK UhmZaj3rIxIkSE75xim32jhzNOGk94Zof8kp8= MIME-Version: 1.0 Received: by 10.142.207.13 with SMTP id e13mr396026wfg.21.1273746402676; Thu, 13 May 2010 03:26:42 -0700 (PDT) Received: by 10.142.193.6 with HTTP; Thu, 13 May 2010 03:26:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 May 2010 14:26:42 +0400 Message-ID: From: Alexander Churanov To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if statements 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, 13 May 2010 10:26:43 -0000 2010/5/11 Eitan Adler : > My proposal is simple: > require that any if statement that compares a constant to a mutable variable > be written as > if (constant == variable) > instead of > if (variable == constant) Use "const" qualification. It's portable and does not require rewriting conditionals in any way. Alexander Churanov From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 15:01:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8A351065677 for ; Thu, 13 May 2010 15:01:22 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3F18FC0A for ; Thu, 13 May 2010 15:01:21 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so160577eyd.9 for ; Thu, 13 May 2010 08:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Neg0i+wV7XVrITeHU5MEu9rYkFc1MBrOjMQD737WwJA=; b=aZkjd06tQ849spgdhP1//kr67P4i7sGrN93/0AzhcJYPW5gl8UMzT2sAo2h7aQWXRA 0MKRQxMp9HquO8EEBFREathbBlPLbxtvzYQmj3GfP1nqemVJilBiyCdEtev/2JR0/0eX RVASTZR3tWdYsx3GjsW3shLZb6qo4Fevvpnpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cNNWhSSWQNebmjGTTXa0DRSZ4x7DoOkrkp029euFCUwsAw3Nrr3jmPXldokCdgy3IP 67vFFriXZ9Z+hkw4U2TLDSdtv4uun5TexFs9+H8o2LmrLZc5LdIqkbUfWCT380m7cGoa 4qLm81Mj1kEd4opSsNOBsqahA4KFF9jXxihs8= MIME-Version: 1.0 Received: by 10.213.55.13 with SMTP id s13mr1465492ebg.34.1273762881174; Thu, 13 May 2010 08:01:21 -0700 (PDT) Received: by 10.213.35.197 with HTTP; Thu, 13 May 2010 08:01:20 -0700 (PDT) Date: Thu, 13 May 2010 19:01:20 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Need advice about selsocket analogue for a set of sockets 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, 13 May 2010 15:01:22 -0000 Hi Hackers, I know that FreeBSD-8 kernel provides selsocket function declared as follows: int selsocket(struct socket *so, int events, struct timeval *tvp, struct thread *td); It's very useful if you have just one socket and don't care about which events fired. In my case, however, I have an array of the following structures typedef struct { struct socket *fd; int events; int revents; } sock_poll_t; and need to poll all sockets saving results in revents field. That is I need to implement a function with the following prototype: int sockets_poll( sock_poll_t * ufds, unsigned int nfds, int timeout_msecs); Obviously, selsocket is useless is such scenario (it returns 0 on success and therefore doesn't tell which events fired). I looked into sys/kern/sys_generic.c but didn't find any functions which may be useful for working with array of structures above. I could try to implement a function similar to selsocket, but I cannot use the same helper functions (selfdalloc, seltdwait, etc) because they are considered as implementation details and defined as static. I need your advice. What's the best way of solving my problem? Thanks in advance! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 17:45:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF78D1065674 for ; Thu, 13 May 2010 17:45:25 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 219898FC16 for ; Thu, 13 May 2010 17:45:24 +0000 (UTC) Received: from park.js.berklix.net (p549A2B9F.dip.t-dialin.net [84.154.43.159]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4DHjLX1050593 for ; Thu, 13 May 2010 17:45:22 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4DHjFEb019298 for ; Thu, 13 May 2010 19:45:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4DHiw7x016383 for ; Thu, 13 May 2010 19:45:15 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005131745.o4DHiw7x016383@fire.js.berklix.net> To: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Thu, 13 May 2010 19:44:58 +0200 Sender: jhs@berklix.com Subject: /dev/null & zero inside chroot for make release 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, 13 May 2010 17:45:25 -0000 Hi Hackers, Problem with /dev/null & /dev/zero inside a chroot: I wanted to build a release from inside a chroot ( So /var/db/pkg matches what's required by make release, without changing packages on outside the chroot, + Also to experiment with http://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056705.html ) Using 8.0-Release & amd64 I built a chroot, (from memory, approx by: cd /usr/src ; make world setenv DESTDIR /usrb/chroot cd /usr/src/etc ; make distrib-dirs cd /usr/src ; make install ) source `which unsetenv.csh` # remove my aliases etc. chroot /usrb/chroot cd /dev rm null zero ; mknod null c 0 31 ; mknod zero c 0 32 cd /usr/src ; make make: cannot open /dev/null. "/usr/src/Makefile", line 111: warning: "/usr/bin/env -i PATH=/sbin:/bin:/usr/sbin:/usr/bin make __MAKE_CONF=/etc/make.conf -f /dev/null -V MAKEOBJDIRPREFIX dummy" returned non-zero status make: cannot open /dev/null. "/usr/src/Makefile.inc1", line 157: warning: "MAKEFLAGS= CPUTYPE=dummy make -f /dev/null -m /usr/src/share/mk -V CPUTYPE" returned non-zero status "/usr/src/Makefile.inc1", line 159: CPUTYPE global should be set with ?=. *** Error code 1 cd /dev/ rm null zero ; touch null cd /usr/src ; make Runs OK to here ===> sys/boot/i386/boot2 (all) dd if=/dev/zero of=boot2.ldr bs=512 count=1 dd: /dev/zero: No such file or directory *** Error code 1 What sort of null & zero should be in chroot ? man mknod ... deprecated ... Should I be running a devfs (I'm not currently) Or a jail ? (I dont really want that level of encapsulation ). Cheers, Julian - - -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org - ------- End of Unsent Draft ------- End of Forwarded Message From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 18:06:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97010106566B for ; Thu, 13 May 2010 18:06:08 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 5AFD28FC15 for ; Thu, 13 May 2010 18:06:08 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id C050D1DD63C; Thu, 13 May 2010 20:06:06 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id B390C1752A; Thu, 13 May 2010 20:06:06 +0200 (CEST) Date: Thu, 13 May 2010 20:06:06 +0200 From: Jilles Tjoelker To: "Julian H. Stacey" Message-ID: <20100513180606.GA43485@stack.nl> References: <201005131745.o4DHiw7x016383@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005131745.o4DHiw7x016383@fire.js.berklix.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/null & zero inside chroot for make release 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, 13 May 2010 18:06:08 -0000 On Thu, May 13, 2010 at 07:44:58PM +0200, Julian H. Stacey wrote: > Problem with /dev/null & /dev/zero inside a chroot: > I wanted to build a release from inside a chroot > What sort of null & zero should be in chroot ? > man mknod ... deprecated ... > Should I be running a devfs (I'm not currently) > Or a jail ? (I dont really want that level of encapsulation ). Mount devfs in your chroot. Then use devfs(8) to limit what's visible in that particular devfs, if you want. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 18:13:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CE19106564A for ; Thu, 13 May 2010 18:13:44 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DF3768FC17 for ; Thu, 13 May 2010 18:13:43 +0000 (UTC) Received: by vws1 with SMTP id 1so1655040vws.13 for ; Thu, 13 May 2010 11:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=aHTa0qYGjwylqoY19Qt8k+pZba9zD23m6hxECnAtIRM=; b=bOn/oYca9UIYWBK44/OXrBN7TvBOuaKiakveqMxP3mEl52wbDaej5dAnbIuQAyxVho usfkfGepvjps6MmZxKLxT6P2aa8XFC6gVnmWRSz9wW2YIxskxQmgvHqO6oDP4kWsof8A Eq7rdrKNmbkkn9zXbdSmrKwgwPlVLOOhb+ab4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=OI60eolfju8McXchC9bd0wTINlT2yLNDVZZ/WWQ+QGHvGiFiJLBHy+P4cZEfV2oVkS HbMbAI6n87YWN90ejHUEWoJgkCUsyQlgo6po371X4ib9UaJmwMThQF5Ikb9h1AELL3T/ 8TpyKOF8wKG5cEbr5U+F6XeMeUON4b/meHlmw= Received: by 10.220.62.198 with SMTP id y6mr6861323vch.1.1273774422897; Thu, 13 May 2010 11:13:42 -0700 (PDT) Received: from [172.24.100.213] ([192.75.139.253]) by mx.google.com with ESMTPS id s9sm6626084vcr.3.2010.05.13.11.13.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 11:13:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20100513180606.GA43485@stack.nl> Date: Thu, 13 May 2010 14:13:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5E6781BD-D744-4BAA-A907-5FCD142A207A@gmail.com> References: <201005131745.o4DHiw7x016383@fire.js.berklix.net> <20100513180606.GA43485@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1078) Cc: freebsd-hackers@freebsd.org, "Julian H. Stacey" Subject: Re: /dev/null & zero inside chroot for make release 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, 13 May 2010 18:13:44 -0000 On May 13, 2010, at 2:06 PM, Jilles Tjoelker wrote: > On Thu, May 13, 2010 at 07:44:58PM +0200, Julian H. Stacey wrote: >> Problem with /dev/null & /dev/zero inside a chroot: >> I wanted to build a release from inside a chroot > >> What sort of null & zero should be in chroot ? >> man mknod ... deprecated ... >> Should I be running a devfs (I'm not currently) >> Or a jail ? (I dont really want that level of encapsulation ). > > Mount devfs in your chroot. Then use devfs(8) to limit what's visible in > that particular devfs, if you want. You may also need to run /etc/rc.d/ldconfig the first time as well. HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 21:21:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A0651065675 for ; Thu, 13 May 2010 21:21:16 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC638FC1E for ; Thu, 13 May 2010 21:21:15 +0000 (UTC) Received: by fxm17 with SMTP id 17so883820fxm.13 for ; Thu, 13 May 2010 14:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:x-mailer; bh=BGa5f6iRpUKwRErFk2hOCOlL4J3nawBX/uXlxIbTU4M=; b=eMSsHAD5k7mbIqAikUhZlnaYX7RwPKCIozGG6cq19jWElhv84jLwwOHyuQWFG3lLsy TapFwtWz8JAcMUFEu3ln6ukfM4DRJPkZ142gVlwVtJbRP1SNSXwnXxxWpfIhwQCHr/Ju v0fcyVKKyJsM/VMrgnntFuSZ7h+eTKPi3JWhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:x-mailer; b=QsBm/kSdQ4qDbGhZCUFHY2KW7X6qipvIlq9adLepesuftkfSzO7eVVcZR9ahTQ0Npk a4J4qQKwW/rrqT6vsGsUVjI7R6wNDdKVzplqO3P9/PbQr3ObB5U5cNuNZO6YtLTsgiyL NtqlwtDUW5nRs3k1IvgLRHQEmOrpi5OKQiwwI= Received: by 10.223.40.136 with SMTP id k8mr503017fae.24.1273784023395; Thu, 13 May 2010 13:53:43 -0700 (PDT) Received: from DEV (93-138-126-208.adsl.net.t-com.hr [93.138.126.208]) by mx.google.com with ESMTPS id r25sm7476228fai.11.2010.05.13.13.53.42 (version=SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 13:53:42 -0700 (PDT) Message-ID: <20100513.205343.421.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Date: Thu, 13 May 2010 22:53:43 +0200 X-Mailer: POP Peeper (3.6.0.0) Subject: Custom USB layout & sysinstall (Starting FIXIT) 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, 13 May 2010 21:21:16 -0000 So, I downloaded USB stick .img Instead of just writing it with dd, I've mounted and dumped it, as I wanted custom USB stick, layout. To cut it short. Bootable img file appears as ad0s2a instead of ad0a. Once I boot from BIOS->USB stick->slice 2, I enter sysinstall successfully. Now I wana enter into FIXIT, from sysinstall. And I get "No USB devices found!", as well as, at all other parts, of sysinstall, that search for USB device. Other parts of sysinstall, DO list ad4 (my HDD) and da0 (my USB stick) correctly. I think sysinstall has hardcoded command, to mount da0a and doesn't see da0sxa, at all. So how do I do it manually? Emergency Holo Sh is no go. Maybe this part of code is responsible, from file /usr/src/usr.sbin/sysinstall/devices.c: Code: /* * Find all devices that match the criteria, allowing "wildcarding" as well * by allowing NULL or ANY values to match all. The array returned is static * and may be used until the next invocation of deviceFind(). */ Device ** deviceFind(char *name, DeviceType class) { static Device *found[DEV_MAX]; int i, j; j = 0; for (i = 0; i < numDevs; i++) { if ((!name || !strcmp(Devices[i]->name, name)) && (class == DEVICE_TYPE_ANY || class == Devices[i]->type)) found[j++] = Devices[i]; } found[j] = NULL; return j ? found : NULL; } PS: Options --> Rescan Devices, in sysinstall don't work. Could I start fixit, from loader prompt directly, so I wouldn't even have to eneter sysinstall, as I don't need it at all to install FreeBSD? From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 22:11:33 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD14C1065676 for ; Thu, 13 May 2010 22:11:33 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 271DA8FC12 for ; Thu, 13 May 2010 22:11:32 +0000 (UTC) Received: from park.js.berklix.net (p549A3F72.dip.t-dialin.net [84.154.63.114]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4DMBR2P052612; Thu, 13 May 2010 22:11:29 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4DMBKEh081588; Fri, 14 May 2010 00:11:21 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4DMB4sG018935; Fri, 14 May 2010 00:11:09 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005132211.o4DMB4sG018935@fire.js.berklix.net> To: rank1seeker@gmail.com From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 13 May 2010 22:53:43 +0200." <20100513.205343.421.1@DEV> Date: Fri, 14 May 2010 00:11:04 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, Ken Smith Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) 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, 13 May 2010 22:11:33 -0000 Hi, rank1seeker@gmail.com wrote: > So, I downloaded USB stick .img > Instead of just writing it with dd, I've mounted and dumped it, as I wanted > custom USB stick, layout. > > To cut it short. > Bootable img file appears as ad0s2a instead of ad0a. > Once I boot from BIOS->USB stick->slice 2, I enter sysinstall successfully. > > Now I wana enter into FIXIT, from sysinstall. > And I get "No USB devices found!", as well as, at all other parts, of > sysinstall, that search for USB device. I reported the same thing as you a month back. http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031534.html Subject: Bug with fixit live 8.0 memstick.img running on F1 after MBR From: "Julian H. Stacey" Date: Sat, 17 Apr 2010 12:05:46 +0200 To: hackers@freebsd.org Message-id: <201004171005.o3HA5kfo014359@fire.js.berklix.net> I didn't get as far analysing as you did below. Ken Smith (cc'd) posted ideas, but I got distracted on to other things. Ken's post is here: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031620.html > Other parts of sysinstall, DO list ad4 (my HDD) and da0 (my USB stick) > correctly. > > > I think sysinstall has hardcoded command, to mount da0a and doesn't see > da0sxa, at all. > > So how do I do it manually? > Emergency Holo Sh is no go. > > > Maybe this part of code is responsible, from file > /usr/src/usr.sbin/sysinstall/devices.c: > Code: > > /* > * Find all devices that match the criteria, allowing "wildcarding" as well > * by allowing NULL or ANY values to match all. The array returned is > static > * and may be used until the next invocation of deviceFind(). > */ > Device ** > deviceFind(char *name, DeviceType class) > { > static Device *found[DEV_MAX]; > int i, j; > > j = 0; > for (i = 0; i < numDevs; i++) { > if ((!name || !strcmp(Devices[i]->name, name)) > && (class == DEVICE_TYPE_ANY || class == Devices[i]->type)) > found[j++] = Devices[i]; > } > found[j] = NULL; > return j ? found : NULL; > } > > PS: > Options --> Rescan Devices, in sysinstall don't work. > > Could I start fixit, from loader prompt directly, so I wouldn't even have > to eneter sysinstall, as I don't need it at all to install FreeBSD? Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Thu May 13 22:35:25 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D5B106566B for ; Thu, 13 May 2010 22:35:25 +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 49D928FC14 for ; Thu, 13 May 2010 22:35:25 +0000 (UTC) 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 o4DLQjxm011131; Thu, 13 May 2010 17:26:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 13 May 2010 17:26:44 -0400 To: Eitan Adler , hackers@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0704 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Cc: Subject: Re: proposed change to style(9): require yoda style if statements 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, 13 May 2010 22:35:25 -0000 At 10:36 PM +0300 5/11/10, Eitan Adler wrote: >My proposal is simple: >require that any if statement that compares a constant to a mutable variable >be written as >if (constant == variable) >instead of >if (variable == constant) > >this prevents an extremely common programming error >if (variable = constant) I did this for awhile in my own programming, long enough ago that there was no cool "yoda" name connected to it. But I found that in some situations it makes the code harder to read, so I don't do it as much any more. I don't mind if people do it, but I do not think it should be an official recommendation in style(9). Or to say it another way, I'd be annoyed if an otherwise-correct patch was asked to be rewritten just because the developer used (variable == constant) instead of (constant == variable). -- 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 Thu May 13 23:16:41 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C11C7106566B; Thu, 13 May 2010 23:16:41 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 689018FC08; Thu, 13 May 2010 23:16:41 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 73198A69E26; Fri, 14 May 2010 07:16:40 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id kdtcUO7z1bAq; Fri, 14 May 2010 07:16:22 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 194A0A69D3E; Fri, 14 May 2010 07:16:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Q15MAmm/82GGUZvPDk2y86CS7z2u8FJzb7C+jEK6p34ytN/PZXdANtMGhzvcqsY7P T53v3hXk/0D63DsDCSwdw== Message-ID: <4BEC883F.1060602@delphij.net> Date: Thu, 13 May 2010 16:16:15 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100408 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Garance A Drosehn References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eitan Adler , hackers@FreeBSD.org Subject: Re: proposed change to style(9): require yoda style if statements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 23:16:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/05/13 14:26, Garance A Drosehn wrote: > At 10:36 PM +0300 5/11/10, Eitan Adler wrote: >> My proposal is simple: >> require that any if statement that compares a constant to a mutable >> variable >> be written as >> if (constant == variable) >> instead of >> if (variable == constant) >> >> this prevents an extremely common programming error >> if (variable = constant) > > > I did this for awhile in my own programming, long enough ago that > there was no cool "yoda" name connected to it. But I found that in > some situations it makes the code harder to read, so I don't do it > as much any more. I don't mind if people do it, but I do not think > it should be an official recommendation in style(9). Or to say it > another way, I'd be annoyed if an otherwise-correct patch was asked > to be rewritten just because the developer used (variable == constant) > instead of (constant == variable). I used to use this style of programming a lot but gave up ~7 years ago when I found that some C++ compiler can be confused in very ugly manner (due to type mismatch), not to mention that using this style sometimes makes the code harder to read. It turns out that modern compilers are more sensitive about this type of mistakes, and, more importantly, making code more readable would usually save debugging time. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL7Ig/AAoJEATO+BI/yjfBiQwH/R6nlA5DciXXHfl1XDxDMe81 fnmOCgCAbidKySiwlmKJhsfLuZgKQX/jVqO2Z28X+0cOQVqLw2bZ9hlfyZ306uGy vwYDXzs+E805T+S9UArKe7jJdoeuQajJ7w+Z0eJfCjFBgb9KCW/KTIaPaFJJtvbS azVB0q7tuZGd2xPj6iNmuxteeN1B0aixYNov5cGtSs3anH9rwFPFqJAntN8nRWTm 0W9ocOgi/cNYfNMuapvxSsRv2IJiAe+EpikpRhDJT2ushFnQ1ML4a2Mgld7sz+jn YvYHUi5LAnyl7oIS5hxF7d7ADINmPuKnoBNbgiYoMLpNjsE1thAsXPFv8SWI3qs= =ngfR -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 14 11:53:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37848106564A for ; Fri, 14 May 2010 11:53:22 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04A788FC21 for ; Fri, 14 May 2010 11:53:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 92B4646B92; Fri, 14 May 2010 07:53:21 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9971B8A021; Fri, 14 May 2010 07:53:20 -0400 (EDT) Message-ID: <4BED2B27.2020902@FreeBSD.org> Date: Fri, 14 May 2010 06:51:19 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ali Polatel References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> <20100510164847.GF8186@harikalardiyari> <20100510170947.GP83316@deviant.kiev.zoral.com.ua> <20100511103500.GH8186@harikalardiyari> In-Reply-To: <20100511103500.GH8186@harikalardiyari> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 14 May 2010 07:53:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 14 May 2010 11:53:22 -0000 Ali Polatel wrote: > Kostik Belousov yazmış: >> On Mon, May 10, 2010 at 07:48:47PM +0300, Ali Polatel wrote: >>> Another question is how hard is it to implement PL_EVENT_EXEC? >>> This could be useful for truss as it updates the execution type of the >>> process after successful execve() calls afaict. >> Is this needed ? The question is not rhetorical, I am trying to >> understand what prevents use of PT_TO_SCE and checking the syscall >> number ? You would screen for SYS_execve or SYS_fexecve and >> reset the debugger state on SIGTRAP that is supplied to the debugger >> before first instruction of new image is executed. >> > > Not really needed, just cleaner imo. As system call numbers may be > different for different execution types and you need to look it up from > a table using a string as argument which is slow. I agree that this would be cleaner. Having worked on the ptrace/procfs stuff in other tools like strace and truss, exec truly is an important event to a debugger aside from just being another system call as it signals that the address space has been changed. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri May 14 12:57:37 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2567106564A; Fri, 14 May 2010 12:57:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 126EA8FC1A; Fri, 14 May 2010 12:57:36 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4ECviq0081185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 15:57:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4ECvVnN023328; Fri, 14 May 2010 15:57:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4ECvVsi023327; Fri, 14 May 2010 15:57:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 May 2010 15:57:31 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20100514125731.GP83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> <20100510164847.GF8186@harikalardiyari> <20100510170947.GP83316@deviant.kiev.zoral.com.ua> <20100511103500.GH8186@harikalardiyari> <4BED2B27.2020902@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9rkt7tfZQigMla7f" Content-Disposition: inline In-Reply-To: <4BED2B27.2020902@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ali Polatel , freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps 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, 14 May 2010 12:57:38 -0000 --9rkt7tfZQigMla7f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 14, 2010 at 06:51:19AM -0400, John Baldwin wrote: > Ali Polatel wrote: > >Kostik Belousov yazm????: > >>On Mon, May 10, 2010 at 07:48:47PM +0300, Ali Polatel wrote: > >>>Another question is how hard is it to implement PL_EVENT_EXEC? > >>>This could be useful for truss as it updates the execution type of the > >>>process after successful execve() calls afaict. > >>Is this needed ? The question is not rhetorical, I am trying to > >>understand what prevents use of PT_TO_SCE and checking the syscall > >>number ? You would screen for SYS_execve or SYS_fexecve and > >>reset the debugger state on SIGTRAP that is supplied to the debugger > >>before first instruction of new image is executed. > >> > > > >Not really needed, just cleaner imo. As system call numbers may be > >different for different execution types and you need to look it up from > >a table using a string as argument which is slow. >=20 > I agree that this would be cleaner. Having worked on the ptrace/procfs= =20 > stuff in other tools like strace and truss, exec truly is an important=20 > event to a debugger aside from just being another system call as it=20 > signals that the address space has been changed. Ok, I would not much object. But I finally tired of adding the same code to three places (ignoring !x86 arches). diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index d5ddc59..39eb435 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -170,7 +170,7 @@ static int prot_fault_translation =3D 0; SYSCTL_INT(_machdep, OID_AUTO, prot_fault_translation, CTLFLAG_RW, &prot_fault_translation, 0, "Select signal to deliver on protection fault= "); =20 -extern char *syscallnames[]; +extern const char *syscallnames[]; =20 /* * Exception, fault, and trap interface to the FreeBSD kernel. @@ -884,7 +884,7 @@ syscall(struct trapframe *frame) struct proc *p; struct syscall_args sa; register_t orig_tf_rflags; - int error; + int error, traced; ksiginfo_t ksi; =20 PCPU_INC(cnt.v_syscall); @@ -905,10 +905,13 @@ syscall(struct trapframe *frame) cred_update_thread(td); orig_tf_rflags =3D frame->tf_rflags; if (p->p_flag & P_TRACED) { + traced =3D 1; PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); - } + } else + traced =3D 0; error =3D fetch_syscall_args(td, &sa); =20 CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, @@ -961,6 +964,11 @@ syscall(struct trapframe *frame) #endif } retval: + if (traced) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -975,40 +983,5 @@ syscall(struct trapframe *frame) trapsignal(td, &ksi); } =20 - /* - * Check for misbehavior. - */ - WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - syscallnames[sa.code] : "???"); - KASSERT(td->td_critnest =3D=3D 0, - ("System call %s returning in a critical section", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - syscallnames[sa.code] : "???")); - KASSERT(td->td_locks =3D=3D 0, - ("System call %s returning with %d locks held", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - syscallnames[sa.code] : "???", td->td_locks)); - - /* - * Handle reschedule and other end-of-syscall issues - */ - userret(td, frame); - - CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_name, sa.code); - -#ifdef KTRACE - if (KTRPOINT(td, KTR_SYSRET)) - ktrsysret(sa.code, error, td->td_retval[0]); -#endif - - /* - * This works because errno is findable through the - * register set. If we ever support an emulation where this - * is not the case, this code will need to be revisited. - */ - STOPEVENT(p, S_SCX, sa.code); - - PTRACESTOP_SC(p, td, S_PT_SCX); + syscallret(td, error, sa.code, syscallnames); } diff --git a/sys/amd64/ia32/ia32_syscall.c b/sys/amd64/ia32/ia32_syscall.c index aa1ae6c..ad82210 100644 --- a/sys/amd64/ia32/ia32_syscall.c +++ b/sys/amd64/ia32/ia32_syscall.c @@ -170,7 +170,7 @@ ia32_syscall(struct trapframe *frame) struct proc *p; struct ia32_syscall_args sa; register_t orig_tf_rflags; - int error; + int error, traced; ksiginfo_t ksi; =20 PCPU_INC(cnt.v_syscall); @@ -184,10 +184,13 @@ ia32_syscall(struct trapframe *frame) cred_update_thread(td); orig_tf_rflags =3D frame->tf_rflags; if (p->p_flag & P_TRACED) { + traced =3D 1; PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); - } + } else + traced =3D 0; error =3D fetch_ia32_syscall_args(td, &sa); =20 CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, @@ -218,6 +221,11 @@ ia32_syscall(struct trapframe *frame) td->td_errno =3D error; } retval: + if (traced) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -232,44 +240,9 @@ ia32_syscall(struct trapframe *frame) trapsignal(td, &ksi); } =20 - /* - * Check for misbehavior. - */ - WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - freebsd32_syscallnames[sa.code] : "???"); - KASSERT(td->td_critnest =3D=3D 0, - ("System call %s returning in a critical section", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - freebsd32_syscallnames[sa.code] : "???")); - KASSERT(td->td_locks =3D=3D 0, - ("System call %s returning with %d locks held", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - freebsd32_syscallnames[sa.code] : "???", td->td_locks)); - - /* - * Handle reschedule and other end-of-syscall issues - */ - userret(td, frame); - - CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_proc->p_comm, sa.code); -#ifdef KTRACE - if (KTRPOINT(td, KTR_SYSRET)) - ktrsysret(sa.code, error, td->td_retval[0]); -#endif - - /* - * This works because errno is findable through the - * register set. If we ever support an emulation where this - * is not the case, this code will need to be revisited. - */ - STOPEVENT(p, S_SCX, sa.code); -=20 - PTRACESTOP_SC(p, td, S_PT_SCX); + syscallret(td, error, sa.code, freebsd32_syscallnames); } =20 - static void ia32_syscall_enable(void *dummy) { diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c index a11daa6..35df54b 100644 --- a/sys/i386/i386/trap.c +++ b/sys/i386/i386/trap.c @@ -184,7 +184,7 @@ static int prot_fault_translation =3D 0; SYSCTL_INT(_machdep, OID_AUTO, prot_fault_translation, CTLFLAG_RW, &prot_fault_translation, 0, "Select signal to deliver on protection fault= "); =20 -extern char *syscallnames[]; +extern const char *syscallnames[]; =20 /* * Exception, fault, and trap interface to the FreeBSD kernel. @@ -1051,7 +1051,7 @@ syscall(struct trapframe *frame) struct proc *p; struct syscall_args sa; register_t orig_tf_eflags; - int error; + int error, traced; ksiginfo_t ksi; =20 PCPU_INC(cnt.v_syscall); @@ -1072,10 +1072,13 @@ syscall(struct trapframe *frame) cred_update_thread(td); orig_tf_eflags =3D frame->tf_eflags; if (p->p_flag & P_TRACED) { + traced =3D 1; PROC_LOCK(p); td->td_dbgflags &=3D ~TDB_USERWR; + td->td_dbgflags |=3D TDB_SCE; PROC_UNLOCK(p); - } + } else + traced =3D 0; error =3D fetch_syscall_args(td, &sa); =20 CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, @@ -1128,6 +1131,11 @@ syscall(struct trapframe *frame) #endif } retval: + if (traced) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_SCE; + PROC_UNLOCK(p); + } cpu_set_syscall_retval(td, error); =20 /* @@ -1142,41 +1150,6 @@ syscall(struct trapframe *frame) trapsignal(td, &ksi); } =20 - /* - * Check for misbehavior. - */ - WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - syscallnames[sa.code] : "???"); - KASSERT(td->td_critnest =3D=3D 0, - ("System call %s returning in a critical section", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - syscallnames[sa.code] : "???")); - KASSERT(td->td_locks =3D=3D 0, - ("System call %s returning with %d locks held", - (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? - syscallnames[sa.code] : "???", td->td_locks)); - - /* - * Handle reschedule and other end-of-syscall issues - */ - userret(td, frame); - - CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_name, sa.code); - -#ifdef KTRACE - if (KTRPOINT(td, KTR_SYSRET)) - ktrsysret(sa.code, error, td->td_retval[0]); -#endif - - /* - * This works because errno is findable through the - * register set. If we ever support an emulation where this - * is not the case, this code will need to be revisited. - */ - STOPEVENT(p, S_SCX, sa.code); - - PTRACESTOP_SC(p, td, S_PT_SCX); + syscallret(td, error, sa.code, syscallnames); } =20 diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index fc87d63..149e6df 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -871,6 +871,10 @@ exec_fail_dealloc: free(imgp->freepath, M_TEMP); =20 if (error =3D=3D 0) { + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_EXEC; + PROC_UNLOCK(p); + /* * Stop the process here if its stop event mask has * the S_EXEC bit set. diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index 4d20ebd..ea6b0ae 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -58,9 +58,12 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include +#include #include #include #ifdef KTRACE @@ -253,3 +256,61 @@ ast(struct trapframe *framep) userret(td, framep); mtx_assert(&Giant, MA_NOTOWNED); } + +void +syscallret(struct thread *td, int error, u_int sa_code __unused, + const char *scnames[] __unused) +{ + struct proc *p; + int traced; + + p =3D td->td_proc; + + /* + * Check for misbehavior. + */ + WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", + (sa_code >=3D 0 && sa_code < SYS_MAXSYSCALL) ? + scnames[sa_code] : "???"); + KASSERT(td->td_critnest =3D=3D 0, + ("System call %s returning in a critical section", + (sa_code >=3D 0 && sa_code < SYS_MAXSYSCALL) ? + scnames[sa_code] : "???")); + KASSERT(td->td_locks =3D=3D 0, + ("System call %s returning with %d locks held", + (sa_code >=3D 0 && sa_code < SYS_MAXSYSCALL) ? + scnames[sa_code] : "???", td->td_locks)); + + /* + * Handle reschedule and other end-of-syscall issues + */ + userret(td, td->td_frame); + + CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, + td->td_proc->p_pid, td->td_name, sa_code); + +#ifdef KTRACE + if (KTRPOINT(td, KTR_SYSRET)) + ktrsysret(sa_code, error, td->td_retval[0]); +#endif + + if (p->p_flag & P_TRACED) { + traced =3D 1; + PROC_LOCK(p); + td->td_dbgflags |=3D TDB_SCX; + PROC_UNLOCK(p); + } else + traced =3D 0; + /* + * This works because errno is findable through the + * register set. If we ever support an emulation where this + * is not the case, this code will need to be revisited. + */ + STOPEVENT(p, S_SCX, sa_code); + PTRACESTOP_SC(p, td, S_PT_SCX); + if (traced || (td->td_dbgflags & TDB_EXEC) !=3D 0) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~(TDB_SCX | TDB_EXEC); + PROC_UNLOCK(p); + } +} diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index d8cc4f0..6decc02 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -1105,9 +1105,13 @@ kern_ptrace(struct thread *td, int req, pid_t pid, v= oid *addr, int data) pl->pl_lwpid =3D td2->td_tid; if (td2->td_dbgflags & TDB_XSIG) pl->pl_event =3D PL_EVENT_SIGNAL; - else - pl->pl_event =3D 0; pl->pl_flags =3D 0; + if (td2->td_dbgflags & TDB_SCE) + pl->pl_flags |=3D PL_FLAG_SCE; + else if (td2->td_dbgflags & TDB_SCX) + pl->pl_flags |=3D PL_FLAG_SCX; + if (td2->td_dbgflags & TDB_EXEC) + pl->pl_flags |=3D PL_FLAG_EXEC; pl->pl_sigmask =3D td2->td_sigmask; pl->pl_siglist =3D td2->td_siglist; break; diff --git a/sys/sys/proc.h b/sys/sys/proc.h index e32e494..c2b9f4a 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -364,6 +364,9 @@ do { \ #define TDB_SUSPEND 0x00000001 /* Thread is suspended by debugger */ #define TDB_XSIG 0x00000002 /* Thread is exchanging signal under trace */ #define TDB_USERWR 0x00000004 /* Debugger modified memory or registers */ +#define TDB_SCE 0x00000008 /* Thread performs syscall enter */ +#define TDB_SCX 0x00000010 /* Thread performs syscall exit */ +#define TDB_EXEC 0x00000020 /* TDB_SCX from exec(2) family */ =20 /* * "Private" flags kept in td_pflags: @@ -837,6 +840,7 @@ void cpu_switch(struct thread *, struct thread *, struc= t mtx *); void cpu_throw(struct thread *, struct thread *) __dead2; void unsleep(struct thread *); void userret(struct thread *, struct trapframe *); +void syscallret(struct thread *, int, u_int, const char *[]); =20 void cpu_exit(struct thread *); void exit1(struct thread *, int) __dead2; diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h index b30447c..a6dbe2c 100644 --- a/sys/sys/ptrace.h +++ b/sys/sys/ptrace.h @@ -99,6 +99,9 @@ struct ptrace_lwpinfo { int pl_flags; /* LWP flags. */ #define PL_FLAG_SA 0x01 /* M:N thread */ #define PL_FLAG_BOUND 0x02 /* M:N bound thread */ +#define PL_FLAG_SCE 0x04 /* syscall enter point */ +#define PL_FLAG_SCX 0x08 /* syscall leave point */ +#define PL_FLAG_EXEC 0x10 /* exec(2) succeeded */ sigset_t pl_sigmask; /* LWP signal mask */ sigset_t pl_siglist; /* LWP pending signal */ }; --9rkt7tfZQigMla7f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvtSLoACgkQC3+MBN1Mb4iVmgCgzRauK+Y3x7gaHKyV262osh3Z 3D4AoMtpanSlq/21vCDALp0zc+zWABGv =EuVN -----END PGP SIGNATURE----- --9rkt7tfZQigMla7f-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 14 17:16:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BEB41065678 for ; Fri, 14 May 2010 17:16:54 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAAA8FC26 for ; Fri, 14 May 2010 17:16:53 +0000 (UTC) Received: by fxm17 with SMTP id 17so1931332fxm.13 for ; Fri, 14 May 2010 10:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=UH4mYC7lz13x25qzSUfg9TkwQbB7pJPzO/XVtHNYaq0=; b=T5bP17MP3GSsD2Gs9ItL3liCuGWcRH66ffjEk+WQhW4KprlmpRZFzNrgr+ikRddkhI RhQwHbeIr0DeErY93XQZ2FztGg011oOmTAOowLFUAgjrD3w8AE0PbTVZOrtFEcsRjnp6 Nrdt1zyhP9qbEo43Np+jZ9aGniAcGQwDfgRFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hQm44KRhNCddDhplj18bH2dXC88AegQsN9I3mLVezv9DTvBZCOFiqT8qF432n/5ZoH RF92r2grdzCBbhXpqBt9mWDG85DORre3LonCqa6gz2J62rB+3zFj2qhfeDqcHb9hT0tv 2nFnKekhXaFjK0r9oSfMfeGK7x/fWWxeR5ayU= MIME-Version: 1.0 Received: by 10.223.56.206 with SMTP id z14mr1933025fag.97.1273857412499; Fri, 14 May 2010 10:16:52 -0700 (PDT) Received: by 10.223.118.10 with HTTP; Fri, 14 May 2010 10:16:52 -0700 (PDT) In-Reply-To: <201005132211.o4DMB4sG018935@fire.js.berklix.net> References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> Date: Fri, 14 May 2010 19:16:52 +0200 Message-ID: From: none none To: "Julian H. Stacey" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Ken Smith Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) 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, 14 May 2010 17:16:54 -0000 ----- Original Message ----- From: "Julian H. Stacey" To: rank1seeker@gmail.com Cc: freebsd-hackers@freebsd.org, "Ken Smith" Date: Fri, 14 May 2010 00:11:04 +0200 Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) > Hi, > rank1seeker@gmail.com wrote: > > > So, I downloaded USB stick .img > > Instead of just writing it with dd, I've mounted and dumped it, as I wanted > > custom USB stick, layout. > > > > To cut it short. > > Bootable img file appears as ad0s2a instead of ad0a. > > Once I boot from BIOS->USB stick->slice 2, I enter sysinstall successfully. > > > > Now I wana enter into FIXIT, from sysinstall. > > And I get "No USB devices found!", as well as, at all other parts, of > > sysinstall, that search for USB device. > > I reported the same thing as you a month back. > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031534.html > > I didn't get as far analysing as you did below. > Ken Smith (cc'd) posted ideas, but I got distracted on to other things. > Ken's post is here: > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031620.html > I've read it, all. What he is proposing, is about building our own image flavor. (make-memstick.sh) Exactly, that act, is an issue here, as it confuses sysinstall's USB detection. There are 2 remedies: 1) After loader prompt, INSTEAD of starting sysinstall (as I don't need it at all), immediately START Fixit 2) Edit /usr/src/usr.sbin/sysinstall/devices.c, at the code lines, posted below and compile sysinstall, so it could recognize USB device, on non default USB img layout. I favor FIRST solution 1). > > > Other parts of sysinstall, DO list ad4 (my HDD) and da0 (my USB stick) > > correctly. > > > > > > I think sysinstall has hardcoded command, to mount da0a and doesn't see > > da0sxa, at all. > > > > So how do I do it manually? > > Emergency Holo Sh is no go. > > > > > > Maybe this part of code is responsible, from file > > /usr/src/usr.sbin/sysinstall/devices.c: > > Code: > > > > /* > > * Find all devices that match the criteria, allowing "wildcarding" as well > > * by allowing NULL or ANY values to match all. The array returned is > > static > > * and may be used until the next invocation of deviceFind(). > > */ > > Device ** > > deviceFind(char *name, DeviceType class) > > { > > static Device *found[DEV_MAX]; > > int i, j; > > > > j = 0; > > for (i = 0; i < numDevs; i++) { > > if ((!name || !strcmp(Devices[i]->name, name)) > > && (class == DEVICE_TYPE_ANY || class == Devices[i]->type)) > > found[j++] = Devices[i]; > > } > > found[j] = NULL; > > return j ? found : NULL; > > } > > > > PS: > > Options --> Rescan Devices, in sysinstall don't work. > > > > Could I start fixit, from loader prompt directly, so I wouldn't even have > > to eneter sysinstall, as I don't need it at all to install FreeBSD? > > Cheers, > Julian > -- > Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com > Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org > From owner-freebsd-hackers@FreeBSD.ORG Fri May 14 19:59:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E79DD1065673 for ; Fri, 14 May 2010 19:59:54 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 721F18FC12 for ; Fri, 14 May 2010 19:59:54 +0000 (UTC) Received: from park.js.berklix.net (p549A2CFE.dip.t-dialin.net [84.154.44.254]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4EJxqWm070163; Fri, 14 May 2010 19:59:52 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4EJxjLh035069; Fri, 14 May 2010 21:59:47 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4EJxNcJ070942; Fri, 14 May 2010 21:59:28 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005141959.o4EJxNcJ070942@fire.js.berklix.net> To: Garrett Cooper From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 13 May 2010 14:13:52 EDT." <5E6781BD-D744-4BAA-A907-5FCD142A207A@gmail.com> Date: Fri, 14 May 2010 21:59:23 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: /dev/null & zero inside chroot for make release 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, 14 May 2010 19:59:55 -0000 Hi, Garrett Cooper wrote: > On May 13, 2010, at 2:06 PM, Jilles Tjoelker wrote: > > > On Thu, May 13, 2010 at 07:44:58PM +0200, Julian H. Stacey wrote: > >> Problem with /dev/null & /dev/zero inside a chroot: > >> I wanted to build a release from inside a chroot > > > >> What sort of null & zero should be in chroot ? > >> man mknod ... deprecated ... > >> Should I be running a devfs (I'm not currently) > >> Or a jail ? (I dont really want that level of encapsulation ). > > Jilles Tjoelker wrote > > Mount devfs in your chroot. Then use devfs(8) to limit what's visible in > > that particular devfs, if you want. mount | grep devfs devfs on /dev (devfs, local, multilabel) devfs on /var/named/dev (devfs, local, multilabel) Man mount doesnt show syntax. >From man devfs & /etc/rc.subr /etc/rc.d/named I found this works: mount -t devfs dev /usrb/chroot/dev I sent in a send-pr to add a hint for that to man mount. Garrett Cooper wrote: > You may also need to run /etc/rc.d/ldconfig the first time as well. I'll read it. Thanks Jilles & Garrett :-) Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Fri May 14 22:31:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DABCF106566B for ; Fri, 14 May 2010 22:31:31 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0F88FC16 for ; Fri, 14 May 2010 22:31:31 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C66A4C1B3B; Fri, 14 May 2010 18:14:15 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id C67F0C1B09; Fri, 14 May 2010 18:14:12 -0400 (EDT) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 7FCC6C18F0; Fri, 14 May 2010 18:14:12 -0400 (EDT) Received: from ken-smiths-macbook-pro.local (unknown [24.114.252.231]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 10D985B003B; Fri, 14 May 2010 18:14:12 -0400 (EDT) Message-ID: <4BEDCB32.8070206@buffalo.edu> Date: Fri, 14 May 2010 18:14:10 -0400 From: Ken Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: none none References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: : 8% Cc: freebsd-hackers@freebsd.org, "Julian H. Stacey" Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) 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, 14 May 2010 22:31:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/14/10 1:16 PM, none none wrote: > I've read it, all. > What he is proposing, is about building our own image flavor. (make-memstick.sh) > Exactly, that act, is an issue here, as it confuses sysinstall's USB detection. This part of what you say confuses me. I use make-memstick.sh to build the .img files people are downloading and using to do installs with. So if you are using it correctly any machine that can use the .img files I build and we distribute should be able to use what you produce. > There are 2 remedies: > 1) After loader prompt, INSTEAD of starting sysinstall (as I don't > need it at all), immediately START Fixit > 2) Edit /usr/src/usr.sbin/sysinstall/devices.c, at the code lines, > posted below and compile sysinstall, so it could recognize USB device, > on non default USB img layout. > > I favor FIRST solution 1). There are issues with us doing (1) in a widespread way because there are hooks in sysinstall that check to see if it is running as init and it makes lots of decisions based on that. Booting off the install media results in sysinstall running as init, while if you run it later (post-install) it's not running as init. That said, I'm still confused about what's causing you issues. Using text I cut out of this message just to shorten it a bit you said you successfully mounted the memory stick so you could copy stuff out of it, with the intention of modifying it for your purposes. Lets say you copied the contents to /foo, and you made your modifications to it there. After doing your modifications you should be able to do: make-memstick.sh /foo foo.img and the resulting foo.img file should be something you can use in exactly the same way as the .img files I build and distribute. You would need to dd the foo.img file onto a memstick using the same instructions as I give for doing it with the distributed files. I'm not quite sure what could be going wrong if those are the steps you're following. The resulting image should start up sysinstall for you, and you should be able to enter into fixit mode from there. Getting it to skip starting up sysinstall and go straight to fixit mode for you is more complicated, you would need to fiddle a lot more with the pieces you copied out into /foo. Apologies if I'm still not understanding what you're attempting to do - if I'm still "not getting it" can you let us know what piece of the steps above don't accomplish what you're trying to do? Again just to be clear - there should be no difference in how you handle the .img file you create versus the one I created. And the directory /foo I mention above should not be on the memory stick itself, it should be a normal directory on a normal hard drive created by copying the contents of the distributed memory stick image onto the hard drive. - -- Ken Smith - - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvtyzIACgkQ/G14VSmup/aF2ACgleMTRal5LLJSkwj1LU7pPzjx aLUAmwRUVgEp2j/7ifa6n/mGlTbG+nMl =lmMV -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 04:48:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAFF51065678 for ; Sat, 15 May 2010 04:48:03 +0000 (UTC) (envelope-from rychoo@freeshell.net) Received: from sdf.lonestar.org (mx.freeshell.org [192.94.73.19]) by mx1.freebsd.org (Postfix) with ESMTP id 752E78FC23 for ; Sat, 15 May 2010 04:48:03 +0000 (UTC) Received: from [192.168.0.100] (6.ryb.abpl.pl [80.238.64.13]) (authenticated (0 bits)) by sdf.lonestar.org (8.14.4/8.14.3) with ESMTP id o4F4M8mI008062; Sat, 15 May 2010 04:22:39 GMT Content-Transfer-Encoding: quoted-printable From: "Ryszard W. Czekaj" Content-Type: text/plain; charset=iso-8859-2 Message-Id: Date: Sat, 15 May 2010 06:21:17 +0200 To: 4BEABDBE.6080107@bsdforen.de Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: freebsd-hackers@freebsd.org Subject: Re: proposed change to style(9): require yoda style if 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, 15 May 2010 04:48:03 -0000 > The convincing one applies to Java and C++: > if (constant.equals(object)) > instead of > if (object !=3D null && object.equals(constant)) > actually looks easier to read. >=20 > Though you are right about constants being pretty rare. >=20 > > Your .sig is strangely appropriate... >=20 > Not my invention, this is a pretty common one, used by many people > on the net. I actually have no idea where it comes from. I think that this second is safer because using of null object = caught/trow exception in any language, so you are checking at first if = object exist and if you are using by calling object.equals.. --- +48 882 723907 http://Czekaj.net.pl/ Version: 3.12 GIT d- s: a+ C++ UB+++ P+ L- E--- W+++ N+ o-- K++ w++ O M++ V- PS+++ PE- = Y+ PGP+ t 5 X+ R* tv+ b+ DI D++ G e+++ h! r% y+ --- = https://www.paypal.com/cgi-bin/webscr?cmd=3D_s-xclick&hosted_button_id=3DS= QDJ4F2KX3LYG BZ WBK S.A. 1 Oddz. Wodzis=B3aw =A6l=B1ski SWIFT BiC: WBKPPLPP PLN PL 66 1090 1766 0000 0001 1209 3433 EUR PL 74 1090 1766 0000 0001 1209 3433 GBP PL 62 1090 1766 0000 0001 = 1004 4671 From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 07:31:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD081065673 for ; Sat, 15 May 2010 07:31:58 +0000 (UTC) (envelope-from tjado.ml.freebsd-hackers@maecke.net) Received: from mail.xuat.net (maecke.net [85.25.179.71]) by mx1.freebsd.org (Postfix) with ESMTP id F2E268FC16 for ; Sat, 15 May 2010 07:31:56 +0000 (UTC) Received: from [192.168.10.33] (g230241005.adsl.alicedsl.de [92.230.241.5]) by mail.xuat.net (Postfix) with ESMTPSA id 5497551C0; Sat, 15 May 2010 09:12:06 +0200 (CEST) Message-ID: <4BEE4944.4070104@maecke.net> Date: Sat, 15 May 2010 09:12:04 +0200 From: =?ISO-8859-15?Q?Tjado_M=E4cke?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201005131745.o4DHiw7x016383@fire.js.berklix.net> In-Reply-To: <201005131745.o4DHiw7x016383@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/null & zero inside chroot for make release 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, 15 May 2010 07:31:58 -0000 Am 13.05.2010 19:44, schrieb Julian H. Stacey: > Hi Hackers, > Problem with /dev/null & /dev/zero inside a chroot: > I wanted to build a release from inside a chroot > > What sort of null & zero should be in chroot ? > man mknod ... deprecated ... > Should I be running a devfs (I'm not currently) > Or a jail ? (I dont really want that level of encapsulation ). > > http://www.ijs.si/software/amavisd/README.chroot mknod dev/null c 2 2 # FreeBSD Best regards tjado From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 07:16:26 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3951B106566B for ; Sat, 15 May 2010 07:16:26 +0000 (UTC) (envelope-from tjado@maecke.net) Received: from mail.xuat.net (maecke.net [85.25.179.71]) by mx1.freebsd.org (Postfix) with ESMTP id F21888FC0A for ; Sat, 15 May 2010 07:16:25 +0000 (UTC) Received: from [192.168.10.33] (g230241005.adsl.alicedsl.de [92.230.241.5]) by mail.xuat.net (Postfix) with ESMTPSA id 7007051AF; Sat, 15 May 2010 09:05:48 +0200 (CEST) Message-ID: <4BEE47C9.6050402@maecke.net> Date: Sat, 15 May 2010 09:05:45 +0200 From: =?ISO-8859-15?Q?Tjado_M=E4cke?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201005131745.o4DHiw7x016383@fire.js.berklix.net> In-Reply-To: <201005131745.o4DHiw7x016383@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 15 May 2010 11:25:22 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/null & zero inside chroot for make release 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, 15 May 2010 07:16:26 -0000 http://www.ijs.si/software/amavisd/README.chroot mknod dev/null c 2 2 # FreeBSD Best regards tjado From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 12:01:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF8581065670 for ; Sat, 15 May 2010 12:01:40 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6E91C8FC1D for ; Sat, 15 May 2010 12:01:40 +0000 (UTC) Received: by fxm17 with SMTP id 17so2647202fxm.13 for ; Sat, 15 May 2010 05:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XMYslNQZmwJTpnAF9mM7E0GyAVF8Y9nCg6YKZVQ0k7U=; b=gk2husYp4FO4420WNgp0CBpF4JZjS0MjI9Bv4CVp1TY3WPXMyJQkUGGkoRkj4zjDjF GcLWSp5gSSjvRmQEGGQe47xzpeiSPzWKCowZfVvnzgaQrEKu4K4pFgYY+AlSxtXtQfAq +nG988SWEmx/t0Dmncqn8wEfuo31YgQLdLXO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NYEkIQHleTFaA/tvhwtiFUqGaAEIq7h/FXY4cQE5mwUep+9q7UKYib0bM1AA5H3JhP GTxFJKY4hZYp5CgJ+8rw+1FRjQxdf6S8hXHve0hn4/KmcvlXYoG9BGYGquoXqX8KOAVn 7+DSSF4RyGy/MTylU7RjCQGCmyzMom4dprjK0= MIME-Version: 1.0 Received: by 10.223.53.91 with SMTP id l27mr3130633fag.0.1273924899151; Sat, 15 May 2010 05:01:39 -0700 (PDT) Received: by 10.223.118.10 with HTTP; Sat, 15 May 2010 05:01:39 -0700 (PDT) In-Reply-To: <4BEDCB32.8070206@buffalo.edu> References: <20100513.205343.421.1@DEV> <201005132211.o4DMB4sG018935@fire.js.berklix.net> <4BEDCB32.8070206@buffalo.edu> Date: Sat, 15 May 2010 14:01:39 +0200 Message-ID: From: none none To: Ken Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, "Julian H. Stacey" Subject: Re: Custom USB layout & sysinstall (Starting FIXIT) 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, 15 May 2010 12:01:41 -0000 On Sat, May 15, 2010 at 12:14 AM, Ken Smith wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5/14/10 1:16 PM, none none wrote: >> I've read it, all. >> What he is proposing, is about building our own image flavor. (make-mems= tick.sh) >> Exactly, that act, is an issue here, as it confuses sysinstall's USB det= ection. > > This part of what you say confuses me. =A0I use make-memstick.sh to build > the .img files people are downloading and using to do installs with. > So if you are using it correctly any machine that can use the .img > files I build and we distribute should be able to use what you > produce. Ah, I was unclear. When I've put "make-memstick.sh", in bracket, I was referring to similarity of steps. Not to the usage, of actual make-memstick.sh script. There are 2 types of customizations: A) Content (All in UFS) B) Layout (MBR, slices, boot code, bsdlabel,...) make-memstick.sh script is limited only to customization of A), so I am not using it. And shell command which I utilize are far more complex. I do A) and B) customizations, where B) is a culprit, that confuses sysinst= all. Focus on this: Official FreeBSD memstick.img once 'dd'-ed appears as da0a My edition appears as da0s2a ( because of me doing B) ) Once I turn on my machine, at boot time I select USB as a boot device. Then: BIOS -> MBR of da0 -> slice 2 -> boot loader -> sysinstall Now, while in sysinstall, I decide to go in Fixit mode. When I select a USB device, I get an error msg: "No USB devices found!" Other parts of sysinstall, DO list ad4 (my HDD) and da0 (my USB stick) correctly. >> There are 2 remedies: >> =A0 =A0 1) After loader prompt, INSTEAD of starting sysinstall (as I don= 't >> need it at all), immediately START Fixit >> =A0 =A0 2) Edit /usr/src/usr.sbin/sysinstall/devices.c, at the code line= s, >> posted below and compile sysinstall, so it could recognize USB device, >> on non default USB img layout. >> >> I favor FIRST solution 1). > > There are issues with us doing (1) in a widespread way because there > are hooks in sysinstall that check to see if it is running as init > and it makes lots of decisions based on that. =A0Booting off the install > media results in sysinstall running as init, while if you run it later > (post-install) it's not running as init. So then 2) /usr/src/usr.sbin/sysinstall/devices.c: Code: /* * Find all devices that match the criteria, allowing "wildcarding" as well * by allowing NULL or ANY values to match all. The array returned is static * and may be used until the next invocation of deviceFind(). */ Device ** deviceFind(char *name, DeviceType class) { static Device *found[DEV_MAX]; int i, j; j =3D 0; for (i =3D 0; i < numDevs; i++) { if ((!name || !strcmp(Devices[i]->name, name)) && (class =3D=3D DEVICE_TYPE_ANY || class =3D=3D Devices[i]->typ= e)) found[j++] =3D Devices[i]; } found[j] =3D NULL; return j ? found : NULL; } From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 12:11:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56E78106566C for ; Sat, 15 May 2010 12:11:50 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2B48FC19 for ; Sat, 15 May 2010 12:11:50 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id D600F1DD651; Sat, 15 May 2010 14:11:48 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id CA23117540; Sat, 15 May 2010 14:11:48 +0200 (CEST) Date: Sat, 15 May 2010 14:11:48 +0200 From: Jilles Tjoelker To: Tjado =?iso-8859-1?Q?M=E4cke?= Message-ID: <20100515121148.GA72802@stack.nl> References: <201005131745.o4DHiw7x016383@fire.js.berklix.net> <4BEE4944.4070104@maecke.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BEE4944.4070104@maecke.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, "Julian H. Stacey" Subject: Re: /dev/null & zero inside chroot for make release 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, 15 May 2010 12:11:50 -0000 On Sat, May 15, 2010 at 09:12:04AM +0200, Tjado Mäcke wrote: > Am 13.05.2010 19:44, schrieb Julian H. Stacey: > > Hi Hackers, > > Problem with /dev/null & /dev/zero inside a chroot: > > I wanted to build a release from inside a chroot > > What sort of null & zero should be in chroot ? > > man mknod ... deprecated ... > > Should I be running a devfs (I'm not currently) > > Or a jail ? (I dont really want that level of encapsulation ). > http://www.ijs.si/software/amavisd/README.chroot > mknod dev/null c 2 2 # FreeBSD This is deprecated as of FreeBSD 5.0 and does not work at all as of FreeBSD 6.0, see mknod(8). Only device nodes in devfs can be used to access devices. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 12:26:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F8C106566B for ; Sat, 15 May 2010 12:26:12 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 972E78FC13 for ; Sat, 15 May 2010 12:26:10 +0000 (UTC) Received: from park.js.berklix.net (p549A5B52.dip.t-dialin.net [84.154.91.82]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o4FCQ7c7084642; Sat, 15 May 2010 12:26:09 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o4FCPv0M027648; Sat, 15 May 2010 14:26:04 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o4FCPkl3056460; Sat, 15 May 2010 14:25:51 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201005151225.o4FCPkl3056460@fire.js.berklix.net> To: =?ISO-8859-15?Q?Tjado_M=E4cke?= From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sat, 15 May 2010 09:12:04 +0200." <4BEE4944.4070104@maecke.net> Date: Sat, 15 May 2010 14:25:45 +0200 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/null & zero inside chroot for make release 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, 15 May 2010 12:26:12 -0000 Hi, =?ISO-8859-15?Q?Tjado_M=E4cke?= wrote: > Am 13.05.2010 19:44, schrieb Julian H. Stacey: > > Hi Hackers, > > Problem with /dev/null & /dev/zero inside a chroot: > > I wanted to build a release from inside a chroot > > > > What sort of null & zero should be in chroot ? > > man mknod ... deprecated ... > > Should I be running a devfs (I'm not currently) > > Or a jail ? (I dont really want that level of encapsulation ). > > > > > > http://www.ijs.si/software/amavisd/README.chroot > > mknod dev/null c 2 2 # FreeBSD Thanks for trying to help :-) But this is in Wrong. Line 4 on that page: Last updated: 2005-08-11 5 years later, FreeBSD-8.0 has via ls -l /dev/null crw-rw-rw- 1 root wheel 0, 31 May 15 14:17 /dev/null so both major & minor numbers have changed, command now would be mknod dev/null c 0 31 which I already posted in my original Thu, 13 May 2010 19:44:58 +0200 as having tried, but not good enough. As I posted Fri, 14 May 2010 21:59:23 +0200 (but you may not have seen when you posted) > I found this works: > mount -t devfs dev /usrb/chroot/dev Thanks anyway. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 15:32:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 313FD106566C for ; Sat, 15 May 2010 15:32:47 +0000 (UTC) (envelope-from tjado.ml.freebsd-hackers@maecke.net) Received: from mail.xuat.net (maecke.net [85.25.179.71]) by mx1.freebsd.org (Postfix) with ESMTP id E9D5D8FC08 for ; Sat, 15 May 2010 15:32:46 +0000 (UTC) Received: from [192.168.10.33] (g230241005.adsl.alicedsl.de [92.230.241.5]) by mail.xuat.net (Postfix) with ESMTPSA id 66A4352FB; Sat, 15 May 2010 17:32:44 +0200 (CEST) Message-ID: <4BEEBE99.4050105@maecke.net> Date: Sat, 15 May 2010 17:32:41 +0200 From: =?ISO-8859-15?Q?Tjado_M=E4cke?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201005151225.o4FCPkl3056460@fire.js.berklix.net> In-Reply-To: <201005151225.o4FCPkl3056460@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/null & zero inside chroot for make release 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, 15 May 2010 15:32:47 -0000 > Thanks for trying to help :-) But this is in Wrong. > Line 4 on that page: > Last updated: 2005-08-11 > 5 years later, FreeBSD-8.0 has via ls -l /dev/null > crw-rw-rw- 1 root wheel 0, 31 May 15 14:17 /dev/null > so both major & minor numbers have changed, command now would be > mknod dev/null c 0 31 > which I already posted in my original Thu, 13 May 2010 19:44:58 +0200 > as having tried, but not good enough. > > As I posted Fri, 14 May 2010 21:59:23 +0200 (but you may not have > seen when you posted) > > Hm... i did this on 7.2 because chrooted scponly shell with WinSCP support needs it. In this case it works... But I'm wrong because the dev/null with my nod numbers doesn't work correctly and WinSCP looks only if this file is there :D From owner-freebsd-hackers@FreeBSD.ORG Sat May 15 18:46:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D83A1065697; Sat, 15 May 2010 18:46:05 +0000 (UTC) (envelope-from nospam@mgedv.net) Received: from mail.mgedv.net (mail.mgedv.net [213.229.1.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4388FC1F; Sat, 15 May 2010 18:46:05 +0000 (UTC) Received: from my.loop (client.my.loop [255.255.255.255]) Message-ID: From: "no@spam@mgedv.net" To: Date: Sat, 15 May 2010 20:07:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org, freebsd-ports-bugs@freebsd.org Subject: openntpd port for freebsd8: removal of custom arc4random_uniform 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, 15 May 2010 18:46:05 -0000 hi naddy, i'm not sure whether this is relevant or not, but: in the openntpd-4.6 port there's a file called arc4random.c, which gets involved during compilation and linking of openntpd: static linking fails because the function arc4random_uniform (which did not exist on 7.2-RELEASE) is delivered by the OS-libs: compile:/data/compile/compile/openntpd-4.6# make cc -O2 -pipe -Wall -I/data/compile/compile/openntpd-4.6 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -std=gnu99 -fstack-protector -o ntpd ntpd.o buffer.o log.o imsg.o ntp.o ntp_msg.o parse.o config.o server.o client.o util.o ntp_dns.o adjfreq.o arc4random.o -lmd /usr/lib/libc.a(arc4random.o)(.text+0x3f0): In function `arc4random_uniform': : multiple definition of `arc4random_uniform' arc4random.o(.text+0x0): first defined here *** Error code 1 Stop in /data/compile/compile/openntpd-4.6. i tried removing the arc4random.c file from the Makefile and compiled openntpd static without any problems: cc -O2 -pipe -Wall -I/data/compile/compile/openntpd-4.6 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -std=gnu99 -fstack-protector -o ntpd ntpd.o buffer.o log.o imsg.o ntp.o ntp_msg.o parse.o config.o server.o client.o util.o ntp_dns.o adjfreq.o -lmd compile:/data/compile/compile/openntpd-4.6# file ntpd ntpd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, for FreeBSD 8.0 (800107), not stripped my patch looks as follows: --- Makefile.orig 2010-05-15 17:53:31.000000000 +0200 +++ Makefile 2010-05-15 18:02:49.000000000 +0200 @@ -2,7 +2,7 @@ PROG= ntpd SRCS= ntpd.c buffer.c log.c imsg.c ntp.c ntp_msg.c parse.y config.c \ - server.c client.c util.c ntp_dns.c adjfreq.c arc4random.c + server.c client.c util.c ntp_dns.c adjfreq.c CFLAGS+= -Wall -I${.CURDIR} CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes CFLAGS+= -Wmissing-declarations (tested on FREEBSD 8.0-RELEASE) cheers. ps: don't directly reply to me, post to the lists.