From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 17 06:30:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CBCCFDBA; Sun, 17 Mar 2013 06:30:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 273D5325; Sun, 17 Mar 2013 06:30:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2H6UXNL079864; Sun, 17 Mar 2013 08:30:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2H6UXNL079864 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2H6UXco079863; Sun, 17 Mar 2013 08:30:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 08:30:33 +0200 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130317063033.GL3794@kib.kiev.ua> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OjaoFelNtturnNY9" Content-Disposition: inline In-Reply-To: <20130316223339.GA3534@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 06:30:38 -0000 --OjaoFelNtturnNY9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote: > On Sat, Mar 16, 2013 at 09:16:05PM +0200, Konstantin Belousov wrote: >=20 > > IMO sbuf_pad() should be moved to subr_sbuf.c. I find the KPI of > > the sbuf_pad() wrong. You have two separate number, the amount to > > pad to, and the current amount. Natural interface would take the > > two numbers separate instead of the difference. Also, could the > > sbuf_pad() deduce the current amount on its own, this would be the > > best ? >=20 > Hm, I am not sure about this. >=20 > So are you proposing instead of something like this >=20 > sbuf_pad(sb, roundup(x, y) - x, 0); >=20 > to have >=20 > sbuf_pad(sb, x, roundup(x, y), 0)? >=20 > Although it is a little easier to write, it looks less intuitive for > me. E.g. I have troubles how to document this and explain. I can't > reffer x as a current position in sbuf, because it might not be. It is > just a some position, roundup(x,y) is another one, and only their > difference makes sence for sbuf_pad, so why not just to provide this > difference? So >=20 > sbuf_pad(sb, from, to, c); >=20 > looks for me less intutive than >=20 > sbuf_pad(sb, len, c); >=20 > A KPI that would be natural for my case:=20 >=20 > /* start a section that is going to be aligned to sizeof(Elf_Size), > using byte '0' for padding */ > sbuf_padded_start(sb, sizeof(Elf_Size), 0); > /* write something to sbuf */ > sbuf_bcat(sb, data, len); > /* align the sbuf section */ > sbuf_pad(sb); >=20 > This might look a little awkward and would add some overhead for the norm= al > case though... This looks fine, in fact. You might want to call it sbuf_start_section() and sbuf_end_section() ? >=20 > > In register_note(), put spaces around '|' for the malloc line. > >=20 > > It seems that you did not moved the 'ABI hack' for ENOMEM situation for > > sysctl_kern_proc_filedesc() into the rewritten function. > > >=20 > Ah, this is a thing I wanted to discuss but forgot! As I understand > the idea of the 'ABI hack' is: if the output buffer is less than the > size of data we have, truncate our data to the last successfully > written kinfo_file structure and return without error. >=20 > In my code I do reset ENOMEM to 0 (see sysctl_kern_proc_filedesc), but > I don't see a way how using sbuf interface I can truncate req->oldidx > to the last successfully written file: sbuf_bcat() (to internal > buffer) may be successful and the error might appear only later, when > draining. I suspect it will break things if I return with a partial > kinfo_file, but haven't come with a solution yet... All you need is to reset req->oldidx. This could be done outside the sbuf interface, in the top level function implementing the sysctl ? What you propose in the follow-up message should work too, I do not have any preference. >=20 > > Please commit the changes to use pget() in the sysctl handlers separate= ly. > >=20 > > Indents after the else clauses in kern_proc_out() are wrong. >=20 > Do you mean indents after '#ifdef COMPAT_FREEBSD32' block? I did it > that way so if COMPAT_FREEBSD32 sections were removed from the code > the indentation would be correct. I saw this practice through the code > and used it myself before. The sections are not going to be removed. IMHO code should be formatted as if the preprocessor directive lines are not present. Could you point out an example of existing code consistent with your indentation ? >=20 > > Since you are moving the KERN_PROC_ZOMBMASK out of kern_proc.c, > > a comment is needed to describe its usage. I would find it very > > confusing if grep reveals no like of code that sets the flags. > >=20 > > In the comment for sbuf_drain_core_output(), s/drainig/draining/, > > s/sefely/safely/ and s/hold/call us with the process lock held/. > >=20 > > I do not see much sense in the kstack note. The core is dumped when > > the threads are moved into the safe state in the kernel, so you > > cannot catch 'living' stack backtraces for the kernel side of > > things. >=20 > I was afraid of it after I had tried it on real dumps :-( Ok, will > remove the kstack note. >=20 > > On the other hand, things like umask, resources and osrel might be > > of the interest for post-morted analysis. >=20 > This is in my TODO list. >=20 > > I did not looked at the usermode changes. >=20 > Thanks for your suggestions! Will do them. >=20 > --=20 > Mikolaj Golub --OjaoFelNtturnNY9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRWMJAAoJEJDCuSvBvK1Bob4P/iy35q2eLdVJF0sg2TQqzB4q vN2wgPLZ4vLIgjulViGTILG0g8jG8pENecLCaPx3q0F4+s+qHVX26kALe5a1pv/P gsCr0Z30cUxmtgeXCPLFrpSSNwHgvr2dstWMx+NmVa6VISPLTgMDvxnm49XilE5Q q0wG9oyIzHHGGsTkcx4uMWMYILxc0bv+POs1gee6p0/DU3P8dGpljd7I7govZh/6 vhFgyhAgEgAH/puNtvJ23UJ5MWzzZTbhtAVPVSGXN9WZMBPkJ1rtb/TMEfGEUNEB qEHS2xylJtlPXBY06S/dCElxSHC1FmjOp0ezybk5EA6OlkPLu5A4ffoUXfj7gRux DnnafVpMjhEbaQb2qdNevKxtiVksRWQactm+uD7UWNUnJkOnCJTEXBiaiQvlC615 o0TmGIl4P5IjxeeCXTHOtCh62wNx28IjQJQcn+8yOugpRYh13hJxmACh1a8Hoysd OMPwCqclkHANgwIWYf5e3nz3eRzhg25vpnSjtrIGfrIkQ8DN2aWq7VvFLQTMYL+U jeje/ld3Tt0gaQON1qDv6ib8OjMVdHrf52b9ETRa3bZEEBiF7KyN1OkFX1vnebAV JTxo30qp8SCY15JXQq29LEI2ui2Z1BsxVnzlXrjs/gOTIaNpSxjl2V7B07RE0lWs tH8ISXMEReaIemaypkUW =vbxZ -----END PGP SIGNATURE----- --OjaoFelNtturnNY9-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 17 09:19:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14202B27; Sun, 17 Mar 2013 09:19:45 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx1.freebsd.org (Postfix) with ESMTP id EE43A8C7; Sun, 17 Mar 2013 09:19:43 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id 16so4215061wgi.27 for ; Sun, 17 Mar 2013 02:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=tvEzqT5ICUdfJ/vbhwhV3y4+ODOOkKK9cCBjN+GZIC4=; b=JwhY2oWknd9p4nfbYc+2fpLIJ5CaWX5rEmzJv5Ut4xL0oVvfdAiBWGG75s1B+4EhFW 1lNDYgSvTRPG18xZlph32klcUGG5SueqKD6OaFPs4b/0rbMSuKGFcPDRDloR2FSCHyld 0Mu6kKLuIfFyECDo9HYmZo9RymttTx1Z5TGou7+YMyuh0/Vovtemoc6wgr7+csUOqVjT FfkKqAIzXGJOsbgFlpveuOk66eyfWQgpWAIRMVZNeCdLLxJFmADzAAUeCpSZl2NBkq7P kXAkUlL/KZnvnqE79rAW6FJfrvWZB3sqc3/XTXNNIb7+TbgKSVnfWAa1H2vEiRkVMJHv xUXA== X-Received: by 10.194.237.40 with SMTP id uz8mr18956402wjc.49.1363511976696; Sun, 17 Mar 2013 02:19:36 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id fx5sm8019257wib.11.2013.03.17.02.19.34 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 17 Mar 2013 02:19:35 -0700 (PDT) Sender: Mikolaj Golub Date: Sun, 17 Mar 2013 11:19:32 +0200 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130317091930.GA2833@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130317063033.GL3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 09:19:45 -0000 On Sun, Mar 17, 2013 at 08:30:33AM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote: > > A KPI that would be natural for my case: > > > > /* start a section that is going to be aligned to sizeof(Elf_Size), > > using byte '0' for padding */ > > sbuf_padded_start(sb, sizeof(Elf_Size), 0); > > /* write something to sbuf */ > > sbuf_bcat(sb, data, len); > > /* align the sbuf section */ > > sbuf_pad(sb); > > > > This might look a little awkward and would add some overhead for the normal > > case though... > This looks fine, in fact. You might want to call it sbuf_start_section() > and sbuf_end_section() ? Ok, will try this way. Thanks. ... > All you need is to reset req->oldidx. This could be done outside the > sbuf interface, in the top level function implementing the sysctl ? I am afraid at this level I don't know a value to reset req->oldidx to. Reseting it to 0 I think is not a good solution? > What you propose in the follow-up message should work too, I do not > have any preference. Ok. Thanks. > > > Indents after the else clauses in kern_proc_out() are wrong. > > > > Do you mean indents after '#ifdef COMPAT_FREEBSD32' block? I did it > > that way so if COMPAT_FREEBSD32 sections were removed from the code > > the indentation would be correct. I saw this practice through the code > > and used it myself before. > The sections are not going to be removed. IMHO code should be formatted > as if the preprocessor directive lines are not present. Could you point > out an example of existing code consistent with your indentation ? In kern/kern_proc.c my code (get_proc_vector, sysctl_kern_proc_auxv) has such indentation. There were no objection when I introduced it, so I thought it was a right way. But surely I didn't invented such indentation myself. I don't recall if I used some particular examples as a reference then, but here are several examples of such indentation found by quick grep: net/bpf.c-#ifdef BPF_JITTER net/bpf.c- bf = bpf_jitter_enable != 0 ? d->bd_bfilter : NULL; net/bpf.c- if (bf != NULL) net/bpf.c- slen = (*(bf->func))(pkt, pktlen, pktlen); net/bpf.c- else net/bpf.c:#endif net/bpf.c- slen = bpf_filter(d->bd_rfilter, pkt, pktlen, pktlen); kern/kern_conf.c-#if 0 kern/kern_conf.c- if (dev->si_usecount == 0 && kern/kern_conf.c- (dev->si_flags & SI_CHEAPCLONE) && (dev->si_flags & SI_NAMED)) kern/kern_conf.c- ; kern/kern_conf.c- else kern/kern_conf.c:#endif kern/kern_conf.c- if (dev->si_devsw == NULL && dev->si_refcount == 0) { kern/kern_jail.c- if (SV_PROC_FLAG(td->td_proc, SV_ILP32)) { kern/kern_jail.c- uint32_t hid32 = pr->pr_hostid; kern/kern_jail.c- kern/kern_jail.c- error = vfs_setopt(opts, "host.hostid", &hid32, sizeof(hid32)); kern/kern_jail.c- } else kern/kern_jail.c:#endif kern/kern_jail.c- error = vfs_setopt(opts, "host.hostid", &pr->pr_hostid, netinet6/raw_ip6.c- /* Do not inject data into pcb. */ netinet6/raw_ip6.c- INP_RUNLOCK(last); netinet6/raw_ip6.c- } else netinet6/raw_ip6.c:#endif /* IPSEC */ netinet6/raw_ip6.c- if (last != NULL) { netinet6/raw_ip6.c- if (last->inp_flags & INP_CONTROLOPTS || On the other hand there are many examples where indentation is used in the way you prefer. I don't have any strong opinion about this so I will do in the way you suggest. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 17 21:23:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EE8DC7AC for ; Sun, 17 Mar 2013 21:23:54 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 5E36E2F1 for ; Sun, 17 Mar 2013 21:23:54 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id B93183592E5 for ; Sun, 17 Mar 2013 22:23:53 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id A26F32848C; Sun, 17 Mar 2013 22:23:53 +0100 (CET) Date: Sun, 17 Mar 2013 22:23:53 +0100 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org Subject: [patch] SOCK_CLOEXEC, SOCK_NONBLOCK and MSG_CMSG_CLOEXEC Message-ID: <20130317212353.GD65525@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 21:23:55 -0000 Here are some more modifications to allow creating file descriptors with close-on-exec set. Like in linux/glibc, SOCK_CLOEXEC and SOCK_NONBLOCK can be OR'ed in socket() and socketpair()'s type parameter, and MSG_CMSG_CLOEXEC to recvmsg() makes file descriptors (SCM_RIGHTS) atomically close-on-exec. The numerical values for SOCK_CLOEXEC and SOCK_NONBLOCK are as in NetBSD. MSG_CMSG_CLOEXEC is the first free bit for MSG_*. I do not pass the SOCK_* flags to MAC because this may cause incorrect failures and can be done later via fcntl() anyway. I expect audit to cope with the new flags. For MSG_CMSG_CLOEXEC, I had to change unp_externalize to take a flags argument. The parts that are still missing for atomic close-on-exec (a reference of what is needed is at http://austingroupbugs.net/view.php?id=411): * accept4(). Apart from SOCK_CLOEXEC, this does not inherit O_NONBLOCK and O_ASYNC flags like our (but not Linux's) accept() does. O_NONBLOCK can be set using SOCK_NONBLOCK flag. O_ASYNC will have to set using fcntl() for those who still want to use it. The function is a cancellation point like accept() and therefore libthr needs to be modified too. Async-signal-safe. * pipe2(). I think it is best to write into the array from the kernel like socketpair() and not create another assembler wrapper to store two integers into an array. Async-signal-safe. * dup3(). See PR kern/176233. I will add the [EINVAL] if oldd == newd as in Linux and will not support any flags other than O_CLOEXEC. Async-signal-safe. * 'e' mode in popen(). Fairly easy to do using pipe2(). * Probably need to be more lenient with fopen() modes. * mkostemp(). Like mkstemp() but with an open() flags argument. * Allow O_CLOEXEC in posix_openpt(). * posix_spawn_file_actions_adddup2() with oldd == newd turns off close-on-exec flag. * kqueue1() as in NetBSD. This seems less important because a kqueue is not inherited across fork but may be useful in case someone uses exec without fork. Index: lib/libc/sys/socket.2 =================================================================== --- lib/libc/sys/socket.2 (revision 248373) +++ lib/libc/sys/socket.2 (working copy) @@ -115,6 +115,15 @@ which is planned, but not yet implemented, are not described here. .Pp +Additionally, the following flags are allowed in the +.Fa type +argument: +.Pp +.Bd -literal -offset indent -compact +SOCK_CLOEXEC Set close-on-exec on the new descriptor, +SOCK_NONBLOCK Set non-blocking mode on the new socket +.Ed +.Pp The .Fa protocol argument Index: lib/libc/sys/socketpair.2 =================================================================== --- lib/libc/sys/socketpair.2 (revision 248373) +++ lib/libc/sys/socketpair.2 (working copy) @@ -57,6 +57,14 @@ and .Fa sv Ns [1] . The two sockets are indistinguishable. +.Pp +The +.Dv SOCK_CLOEXEC +and +.Dv SOCK_NONBLOCK +flags in the +.Fa type +argument apply to both descriptors. .Sh RETURN VALUES .Rv -std socketpair .Sh ERRORS @@ -79,6 +87,7 @@ .Sh SEE ALSO .Xr pipe 2 , .Xr read 2 , +.Xr socket 2 , .Xr write 2 .Sh HISTORY The Index: lib/libc/sys/recv.2 =================================================================== --- lib/libc/sys/recv.2 (revision 248373) +++ lib/libc/sys/recv.2 (working copy) @@ -121,11 +121,12 @@ function is formed by .Em or Ap ing one or more of the values: -.Bl -column ".Dv MSG_DONTWAIT" -offset indent +.Bl -column ".Dv MSG_CMSG_CLOEXEC" -offset indent .It Dv MSG_OOB Ta process out-of-band data .It Dv MSG_PEEK Ta peek at incoming message .It Dv MSG_WAITALL Ta wait for full request or error .It Dv MSG_DONTWAIT Ta do not block +.It Dv MSG_CMSG_CLOEXEC Ta set received fds close-on-exec .El .Pp The @@ -227,6 +228,10 @@ .Fa cmsg_type set to .Dv SCM_RIGHTS . +The close-on-exec flag on received descriptors is set according to the +.Dv MSG_CMSG_CLOEXEC +flag passed to +.Fn recvmsg . .Pp Process credentials can also be passed as ancillary data for .Dv AF_UNIX Index: share/man/man4/unix.4 =================================================================== --- share/man/man4/unix.4 (revision 248373) +++ share/man/man4/unix.4 (working copy) @@ -153,13 +153,15 @@ .Pp The received descriptor is a .Em duplicate -of the sender's descriptor, as if it were created with a call to -.Xr dup 2 . -Per-process descriptor flags, set with -.Xr fcntl 2 , -are -.Em not -passed to a receiver. +of the sender's descriptor, as if it were created via +.Li dup(fd) +or +.Li fcntl(fd, F_DUPFD_CLOEXEC, 0) +depending on whether +.Dv MSG_CMSG_CLOEXEC +is passed in the +.Xr recvmsg 2 +call. Descriptors that are awaiting delivery, or that are purposely not received, are automatically closed by the system when the destination socket is closed. Index: sys/sys/socket.h =================================================================== --- sys/sys/socket.h (revision 248373) +++ sys/sys/socket.h (working copy) @@ -95,7 +95,15 @@ #endif #define SOCK_SEQPACKET 5 /* sequenced packet stream */ +#if __BSD_VISIBLE /* + * Creation flags, OR'ed into socket() and socketpair() type argument. + */ +#define SOCK_CLOEXEC 0x10000000 +#define SOCK_NONBLOCK 0x20000000 +#endif + +/* * Option flags per-socket. */ #define SO_DEBUG 0x0001 /* turn on debugging info recording */ @@ -459,6 +467,7 @@ #endif #if __BSD_VISIBLE #define MSG_NOSIGNAL 0x20000 /* do not generate SIGPIPE on EOF */ +#define MSG_CMSG_CLOEXEC 0x40000 /* make received fds close-on-exec */ #endif /* Index: sys/sys/domain.h =================================================================== --- sys/sys/domain.h (revision 248373) +++ sys/sys/domain.h (working copy) @@ -51,7 +51,7 @@ void (*dom_destroy) /* cleanup structures / state */ (void); int (*dom_externalize) /* externalize access rights */ - (struct mbuf *, struct mbuf **); + (struct mbuf *, struct mbuf **, int); void (*dom_dispose) /* dispose of internalized rights */ (struct mbuf *); struct protosw *dom_protosw, *dom_protoswNPROTOSW; Index: sys/kern/uipc_socket.c =================================================================== --- sys/kern/uipc_socket.c (revision 248373) +++ sys/kern/uipc_socket.c (working copy) @@ -1727,7 +1727,7 @@ SOCKBUF_UNLOCK(&so->so_rcv); VNET_SO_ASSERT(so); error = (*pr->pr_domain->dom_externalize) - (cm, controlp); + (cm, controlp, flags); SOCKBUF_LOCK(&so->so_rcv); } else if (controlp != NULL) *controlp = cm; @@ -2361,7 +2361,7 @@ cm->m_next = NULL; if (pr->pr_domain->dom_externalize != NULL) { error = (*pr->pr_domain->dom_externalize) - (cm, controlp); + (cm, controlp, flags); } else if (controlp != NULL) *controlp = cm; else Index: sys/kern/uipc_usrreq.c =================================================================== --- sys/kern/uipc_usrreq.c (revision 248373) +++ sys/kern/uipc_usrreq.c (working copy) @@ -288,7 +288,7 @@ static void unp_init(void); static int unp_internalize(struct mbuf **, struct thread *); static void unp_internalize_fp(struct file *); -static int unp_externalize(struct mbuf *, struct mbuf **); +static int unp_externalize(struct mbuf *, struct mbuf **, int); static int unp_externalize_fp(struct file *); static struct mbuf *unp_addsockcred(struct thread *, struct mbuf *); static void unp_process_defers(void * __unused, int); @@ -1695,7 +1695,7 @@ } static int -unp_externalize(struct mbuf *control, struct mbuf **controlp) +unp_externalize(struct mbuf *control, struct mbuf **controlp, int flags) { struct thread *td = curthread; /* XXX */ struct cmsghdr *cm = mtod(control, struct cmsghdr *); @@ -1765,6 +1765,8 @@ fde->fde_file = fdep[0]->fde_file; filecaps_move(&fdep[0]->fde_caps, &fde->fde_caps); + if ((flags & MSG_CMSG_CLOEXEC) != 0) + fde->fde_flags |= UF_EXCLOSE; unp_externalize_fp(fde->fde_file); *fdp = f; } Index: sys/kern/uipc_syscalls.c =================================================================== --- sys/kern/uipc_syscalls.c (revision 248373) +++ sys/kern/uipc_syscalls.c (working copy) @@ -164,25 +164,40 @@ { struct socket *so; struct file *fp; - int fd, error; + int fd, error, type, oflag, fflag; AUDIT_ARG_SOCKET(uap->domain, uap->type, uap->protocol); + + type = uap->type; + oflag = 0; + fflag = 0; + if ((type & SOCK_CLOEXEC) != 0) { + type &= ~SOCK_CLOEXEC; + oflag |= O_CLOEXEC; + } + if ((type & SOCK_NONBLOCK) != 0) { + type &= ~SOCK_NONBLOCK; + fflag |= FNONBLOCK; + } + #ifdef MAC - error = mac_socket_check_create(td->td_ucred, uap->domain, uap->type, + error = mac_socket_check_create(td->td_ucred, uap->domain, type, uap->protocol); if (error) return (error); #endif - error = falloc(td, &fp, &fd, 0); + error = falloc(td, &fp, &fd, oflag); if (error) return (error); /* An extra reference on `fp' has been held for us by falloc(). */ - error = socreate(uap->domain, &so, uap->type, uap->protocol, + error = socreate(uap->domain, &so, type, uap->protocol, td->td_ucred, td); if (error) { fdclose(td->td_proc->p_fd, fp, fd, td); } else { - finit(fp, FREAD | FWRITE, DTYPE_SOCKET, so, &socketops); + finit(fp, FREAD | FWRITE | fflag, DTYPE_SOCKET, so, &socketops); + if ((fflag & FNONBLOCK) != 0) + (void) fo_ioctl(fp, FIONBIO, &fflag, td->td_ucred, td); td->td_retval[0] = fd; } fdrop(fp, td); @@ -648,9 +663,20 @@ struct filedesc *fdp = td->td_proc->p_fd; struct file *fp1, *fp2; struct socket *so1, *so2; - int fd, error; + int fd, error, oflag, fflag; AUDIT_ARG_SOCKET(domain, type, protocol); + + oflag = 0; + fflag = 0; + if ((type & SOCK_CLOEXEC) != 0) { + type &= ~SOCK_CLOEXEC; + oflag |= O_CLOEXEC; + } + if ((type & SOCK_NONBLOCK) != 0) { + type &= ~SOCK_NONBLOCK; + fflag |= FNONBLOCK; + } #ifdef MAC /* We might want to have a separate check for socket pairs. */ error = mac_socket_check_create(td->td_ucred, domain, type, @@ -665,12 +691,12 @@ if (error) goto free1; /* On success extra reference to `fp1' and 'fp2' is set by falloc. */ - error = falloc(td, &fp1, &fd, 0); + error = falloc(td, &fp1, &fd, oflag); if (error) goto free2; rsv[0] = fd; fp1->f_data = so1; /* so1 already has ref count */ - error = falloc(td, &fp2, &fd, 0); + error = falloc(td, &fp2, &fd, oflag); if (error) goto free3; fp2->f_data = so2; /* so2 already has ref count */ @@ -686,8 +712,14 @@ if (error) goto free4; } - finit(fp1, FREAD | FWRITE, DTYPE_SOCKET, fp1->f_data, &socketops); - finit(fp2, FREAD | FWRITE, DTYPE_SOCKET, fp2->f_data, &socketops); + finit(fp1, FREAD | FWRITE | fflag, DTYPE_SOCKET, fp1->f_data, + &socketops); + finit(fp2, FREAD | FWRITE | fflag, DTYPE_SOCKET, fp2->f_data, + &socketops); + if ((fflag & FNONBLOCK) != 0) { + (void) fo_ioctl(fp1, FIONBIO, &fflag, td->td_ucred, td); + (void) fo_ioctl(fp2, FIONBIO, &fflag, td->td_ucred, td); + } fdrop(fp1, td); fdrop(fp2, td); return (0); -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 18 10:44:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 689DA10FD for ; Mon, 18 Mar 2013 10:44:49 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 256042E6 for ; Mon, 18 Mar 2013 10:44:48 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 2866A652CFE; Mon, 18 Mar 2013 09:19:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.96.64] (eb0024.eb.z [192.168.96.64]) by mail.embedded-brains.de (Postfix) with ESMTP id 07D06652CFC; Mon, 18 Mar 2013 09:19:02 +0100 (CET) Message-ID: <5146CDF5.3070308@embedded-brains.de> Date: Mon, 18 Mar 2013 09:19:01 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ryan Stone Subject: Re: Purpose of kqueue_task? References: <51435063.7050907@embedded-brains.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:44:49 -0000 On 03/15/2013 06:19 PM, Ryan Stone wrote: > On Fri, Mar 15, 2013 at 12:46 PM, Sebastian Huber > > wrote: > > Hello, > > I want to port the FreeBSD kqueue implementation to another operating > system (RTEMS in this case) to improve the Erlang support. > > I have difficulties to understand the purpose of the kqueue_task. This > function runs asynchronously. It obtains some locks and wakes up the > normal kqueue channel if (kq->kq_state & KQ_TASKDRAIN) == KQ_TASKDRAIN. > This state is only set in kqueue_close(). So most of the time the > kqueue_task only obtains some locks, clears a flag (KQ_TASKSCHED) and > releases the locks? > > > You missed the most important thing that it does: it calls KNOTE_LOCKED to wake > up any waiters sleeping on this event. I suspect that it had to be done in a > separate task due to lock ordering problems with the kq_global lock. Oh, I was blind. This KNOTE_LOCKED looked more like an assertion to me. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 18 17:21:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 278E4B9D for ; Mon, 18 Mar 2013 17:21:59 +0000 (UTC) (envelope-from gvdl@mac.com) Received: from st11p01mm-asmtp004.mac.com (st11p01mm-asmtp004.mac.com [17.172.204.239]) by mx1.freebsd.org (Postfix) with ESMTP id 00267ACA for ; Mon, 18 Mar 2013 17:21:58 +0000 (UTC) Received: from gvdl-mbp15.jnpr.net (natint3.juniper.net [66.129.224.36]) by st11p01mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MJV000499KEGZ60@st11p01mm-asmtp004.mac.com> for freebsd-hackers@freebsd.org; Mon, 18 Mar 2013 17:21:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-18_01:2013-03-18,2013-03-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=18 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303180134 From: Godfrey van der Linden Subject: kmod linking is very strange Date: Mon, 18 Mar 2013 10:21:50 -0700 References: To: freebsd-hackers@freebsd.org Message-id: <8B0E0420-3E21-4230-97BC-1689225E1B5A@mac.com> MIME-version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:21:59 -0000 I posted this to current, but was steered to hackers.=20 Begin forwarded message: > From: Godfrey Van der Linden > Subject: kmod linking is very strange > Date: 15March, 2013 16:46:13 PDT > To: freebsd-current@freebsd.org >=20 > G'day, All. >=20 > First post so please be gentle ;-). Are the barracudas here? >=20 > Summary: >=20 > Module link-elf will link against static symbols and will fail if the = kernel is not compiled with DDB or the required MODULE_DEPEND has been = stripped of local symbols, see nm -g miibus.ko. I propose that we add a = sysctl & associated boot arg that only allows kmod loading against = externally visible symbols. Then in 11 we can enable this flag by = default. >=20 > In Detail: >=20 > Due to another bug in sys/conf/kmod.mk, = (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D177008, contains a patch) = the miibus.ko exports no symbols. I.e. symbols are 'static'.=20 >=20 > sys/kern/link-elf.c:link_elf_lookup_symbol() is the culprit. After = determining that an external symbol can't be found, it does the = following. >=20 > /* If we have not found it, look at the full table (if loaded) = */ > if (ef->symtab =3D=3D ef->ddbsymtab) > return (ENOENT); >=20 > /* Exhaustive search */ > for (i =3D 0, symp =3D ef->ddbsymtab; i < ef->ddbsymcnt; i++, = symp++) { > strp =3D ef->ddbstrtab + symp->st_name; > if (strcmp(name, strp) =3D=3D 0) { > if (symp->st_shndx !=3D SHN_UNDEF || > (symp->st_value !=3D 0 && > ELF_ST_TYPE(symp->st_info) =3D=3D = STT_FUNC)) { > *sym =3D (c_linker_sym_t) symp; > return (0); > } > return (ENOENT); > } > } >=20 > This code walks the ddbsymtab looking for any symbol, including = locals. >=20 > Any kernel that is not built with DDB or any MODULE_DEPEND dependency = .ko that is stripped will break module loading. >=20 >=20 > Godfrey van der Linden > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 18 21:00:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 48926922 for ; Mon, 18 Mar 2013 21:00:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CF0DCA73 for ; Mon, 18 Mar 2013 21:00:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2IKxwQ0055823; Mon, 18 Mar 2013 22:59:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2IKxwQ0055823 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2IKxv1N055822; Mon, 18 Mar 2013 22:59:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Mar 2013 22:59:57 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: [patch] SOCK_CLOEXEC, SOCK_NONBLOCK and MSG_CMSG_CLOEXEC Message-ID: <20130318205957.GM3794@kib.kiev.ua> References: <20130317212353.GD65525@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YLnPAZt6hMJRJaYl" Content-Disposition: inline In-Reply-To: <20130317212353.GD65525@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:00:09 -0000 --YLnPAZt6hMJRJaYl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 10:23:53PM +0100, Jilles Tjoelker wrote: > Here are some more modifications to allow creating file descriptors with > close-on-exec set. Like in linux/glibc, SOCK_CLOEXEC and SOCK_NONBLOCK > can be OR'ed in socket() and socketpair()'s type parameter, and > MSG_CMSG_CLOEXEC to recvmsg() makes file descriptors (SCM_RIGHTS) > atomically close-on-exec. >=20 > The numerical values for SOCK_CLOEXEC and SOCK_NONBLOCK are as in > NetBSD. MSG_CMSG_CLOEXEC is the first free bit for MSG_*. >=20 > I do not pass the SOCK_* flags to MAC because this may cause incorrect > failures and can be done later via fcntl() anyway. I expect audit to > cope with the new flags. >=20 > For MSG_CMSG_CLOEXEC, I had to change unp_externalize to take a flags > argument. This looks fine to me. The only note I have, which is not directly related to your patch, is the recvmsg(2) behaviour when the undefined flag is passed. The syscall silently ignores the flags. I think this is quite wrong, and would cause interesting (security) implications if the program using the MSG_CMSG_CLOEXEC is run on older kernel which does not interpret the flag. Might be, we should start returning EINVAL for unknown flag, despite SUSv4 not specifying the condition ? --YLnPAZt6hMJRJaYl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRR4BNAAoJEJDCuSvBvK1BYTwQAJG6hk1PePBZhmAzMo+QMc7J yfZG+dTpSeqz+/KXRz/+unuL5MgaRtirMEFKfIFk0SgXbLN0BR6OC9XdGKeBH+xZ Fc0wm4wzdmzvC79NJjV+kNBEm/lYr3zRdr2CFpkDf/YsAdP828tyTpjWqqe4bVrk slFuWBu/cUFGwlK3xRTtIpNeKFh1f5g7Xcl9eAscqK9HupbhcKVPItvhL+zoN6FF a2qBXDC7BBmNDgxExrcyZwIELkcRGa33vdVjln4foaeidkquu+RZ9AgqqcvW/S6S F0gd+GuCTv+72ZDDy3zjMm39JJqHJa7Cy/+Bq8+j2kcelvGfE2I5RWQ0dAo4GACV 1pW5ZeqPD9O4vOjUrG/jrpKokz/dnKdsumUubqN/WMZWkhKg0md0ummpI2vXi4XO MPoJZBsnTBR/tHyCJBiX+Ej8ReZSMt/ADCMD/cq4ZraE6719HU+V2wxR8kI/6ivY S/z8MQeO2wmDhLa5YOdo1NsvlKqaSEgKthay3yc3QBEJItrv1Ht9ycsVWRkh2og7 7twEBY1J2vRcBUcnD2WamJubkH4af5Vk+PhwbUzQwpOEs/J1QPASbDTbsTX3e7uS eQNKOV260i7hXNSk4VRc7qn2syvCl6UElEsrT2zVeQGAWTWK5dNHrU59YUcW/ZPI oYo/csOt11C65hWMb75f =nwSl -----END PGP SIGNATURE----- --YLnPAZt6hMJRJaYl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 19 13:15:11 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F178E6F2 for ; Tue, 19 Mar 2013 13:15:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 30DA220A for ; Tue, 19 Mar 2013 13:15:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12653 for ; Tue, 19 Mar 2013 15:15:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UHwNh-000If0-1N for freebsd-hackers@FreeBSD.org; Tue, 19 Mar 2013 15:15:09 +0200 Message-ID: <514864DA.2060503@FreeBSD.org> Date: Tue, 19 Mar 2013 15:15:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: SI_SUB_DTRACE_PROVIDER X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:15:12 -0000 Does anyone know what is the point of SYSINIT(SI_SUB_DTRACE_PROVIDER)? Specifically, as opposed to normal MOD_LOAD/MOD_UNLOAD handling. I am thoroughly confused about DTrace modules using DEV_MODULE() with the dummy handlers and then using SYSINIT/SYSUNINIT when they could use DECLARE_MODULE(SI_SUB_DTRACE_PROVIDER). Especially this is concerning because return values from SYSUNINIT functions are ignored. Unlike MOD_UNLOAD. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 19 13:54:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A877EC0C for ; Tue, 19 Mar 2013 13:54:56 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8B37C3 for ; Tue, 19 Mar 2013 13:54:56 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so532343wib.2 for ; Tue, 19 Mar 2013 06:54:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=mk+XuTauFVp6wdrElBizWFZ1fVvuDGp3urNqCNTDk1c=; b=DVKh3Qfic/ykwaN1KbBv7ohGqdZZqk7cP0qbIpe11s/CR0jfS3CGBOAG8CiAfQBWYM Nj594g7Sq1gN/XkpJzeyb4+S+H5n5HYj6vHJUqMsqDbG1mkjErq/6Ws8XR581Z9I9IOV kNpoflS7RbBp8lgC7Z/8HB1IL0m2fXWfW1RbNiC2NvLy2MEjRXD3WoJjDf68Dj6kfazN XURGxj9jlCG3ZAwmw225E3RmD7gMEdKAIK5MBt1Wg8H6iPhIwmqwpgzyXVGe+90v/ph4 bML1b314vVezeGW9JH8x4Yxeqioh2vFnqZ2k+WTlwPsneDY5EAaIPBb83lS36KZfkrAe sPJg== MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr3404198wjc.50.1363701295536; Tue, 19 Mar 2013 06:54:55 -0700 (PDT) Received: by 10.216.121.212 with HTTP; Tue, 19 Mar 2013 06:54:55 -0700 (PDT) X-Originating-IP: [209.66.78.50] Date: Tue, 19 Mar 2013 09:54:55 -0400 Message-ID: Subject: pkgng questions From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmnsvEm/qZvviIQzC4iZxOESuVgTrxBmR+dcUCqyIJRptLnOwjy/0t7a9PvBFJSATW02vLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:54:56 -0000 All I am wondering if there is a way to prevent a pkg from being updated. For example, i want to build a port with custom options that the pkgng repos will not support, and therefore when I run pkg update && pkg upgrade I do not want it to upgrade my custom package. I cant find any way to do this. Any ideas ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 19 14:12:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62F84271 for ; Tue, 19 Mar 2013 14:12:05 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by mx1.freebsd.org (Postfix) with ESMTP id 3A03C96E for ; Tue, 19 Mar 2013 14:12:05 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id xa12so458797pbc.8 for ; Tue, 19 Mar 2013 07:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kBxgbibGIvFF8xTfeNH4ns2qENtOJkxvu6y68Ic2mWk=; b=Dl2hiv6tV2T+TlBj2iXfxBz0mUjC6NMR3nf4IEt9pGZ7w0PWSHPwb9i7MwlKr7ETk6 AcPi8hig1IzxSaN8sCS1+BlD0bv+7eqnD8012etPzvktk/guy+O3wZaEC25bbdjidK5J vj31Qb1A+yC/uKAIwi7JuPm6zq3Qeg3odfzhNMNwjvdXZfO1jsK2DDKnRpWUeTNpSm5O tMoLlBMvBlnXIzrMy8cjuMC8vSebTVt4YQ2ApA6kWpsargEAEQ0KLhxpa6iFfTlHGjNr ALH9cvouoG82NojhYpYft/7hwv/E1GTfkZbdkMd3WXW02Q1mpb/rwb79sFudtDaTU7N7 +PNA== MIME-Version: 1.0 X-Received: by 10.68.197.193 with SMTP id iw1mr3374795pbc.86.1363702319515; Tue, 19 Mar 2013 07:11:59 -0700 (PDT) Received: by 10.68.36.69 with HTTP; Tue, 19 Mar 2013 07:11:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 16:11:59 +0200 Message-ID: Subject: Re: pkgng questions From: Alexander Yerenkow To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:12:05 -0000 2013/3/19 Mark Saad > All > I am wondering if there is a way to prevent a pkg from being updated. > For example, i want to build a port with custom options that the pkgng > repos will not support, and therefore > when I run pkg update && pkg upgrade I do not want it to upgrade my > custom package. I cant find any way to do this. Any ideas ? > This should be handled when pkg repo will be aware of options. Probably, you'll be asked if you want to change pkg A to pkg B (if they have options different/changed). Also you could pretend that your software is other port :) > > > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > 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" > -- Regards, Alexander Yerenkow From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 19 20:20:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D768E7A for ; Tue, 19 Mar 2013 20:20:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0749D2D5 for ; Tue, 19 Mar 2013 20:20:59 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C52A71203C1; Tue, 19 Mar 2013 21:20:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id AF9A52848C; Tue, 19 Mar 2013 21:20:45 +0100 (CET) Date: Tue, 19 Mar 2013 21:20:45 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: [patch] SOCK_CLOEXEC, SOCK_NONBLOCK and MSG_CMSG_CLOEXEC Message-ID: <20130319202045.GA26721@stack.nl> References: <20130317212353.GD65525@stack.nl> <20130318205957.GM3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130318205957.GM3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:20:59 -0000 On Mon, Mar 18, 2013 at 10:59:57PM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 10:23:53PM +0100, Jilles Tjoelker wrote: > > Here are some more modifications to allow creating file descriptors with > > close-on-exec set. Like in linux/glibc, SOCK_CLOEXEC and SOCK_NONBLOCK > > can be OR'ed in socket() and socketpair()'s type parameter, and > > MSG_CMSG_CLOEXEC to recvmsg() makes file descriptors (SCM_RIGHTS) > > atomically close-on-exec. > > The numerical values for SOCK_CLOEXEC and SOCK_NONBLOCK are as in > > NetBSD. MSG_CMSG_CLOEXEC is the first free bit for MSG_*. > > I do not pass the SOCK_* flags to MAC because this may cause incorrect > > failures and can be done later via fcntl() anyway. I expect audit to > > cope with the new flags. > > For MSG_CMSG_CLOEXEC, I had to change unp_externalize to take a flags > > argument. > This looks fine to me. Thanks for the review. > The only note I have, which is not directly related to your patch, > is the recvmsg(2) behaviour when the undefined flag is passed. > The syscall silently ignores the flags. I think this is quite wrong, > and would cause interesting (security) implications if the program > using the MSG_CMSG_CLOEXEC is run on older kernel which does not > interpret the flag. This is indeed unfortunate and it also affects open(2). It may have originally been done for reasons of modularity; the sys_open() and kern_open() need not know about the valid flag bits this way and a device driver or filesystem can define new bits. The effect of an older kernel ignoring MSG_CMSG_CLOEXEC is probably not that bad, considering that running new userland on an old kernel is not supported. Most compatibility shims for MSG_CMSG_CLOEXEC and similar flags (such as the one in Wayland) simply contain the race condition, so you lose anyway with an old kernel. It would be possible to use closefrom() or an emulation of it or to lock fork() conditionally on the necessary CLOEXEC flags not being available but it appears that people do not go to that trouble. > Might be, we should start returning EINVAL for unknown flag, despite > SUSv4 not specifying the condition ? Per POSIX it is valid to do this but it might cause a compatibility problem if there are applications that pass garbage in flags. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 20 08:30:33 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05DC9CCE; Wed, 20 Mar 2013 08:30:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 05EE5382; Wed, 20 Mar 2013 08:30:31 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA27157; Wed, 20 Mar 2013 10:30:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UIEPm-000NHo-5e; Wed, 20 Mar 2013 10:30:30 +0200 Message-ID: <514973A3.9030706@FreeBSD.org> Date: Wed, 20 Mar 2013 10:30:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org Subject: mountroot event X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:30:33 -0000 I would like to propose the following change. My understanding is that it was never a true intention to post 'mountroot' event on every set_rootvnode() call, but rather an accident in the original commit. But I could be wrong here. In either case I think that it is more appropriate to post the event only once. I do not expect that there could be any consumers interested in all the details of root fs manipulations. It looks like there is just a single subscriber to this event in subr_firmware.c. I am not familiar with that code, so I would like to ask for confirmation that the proposed change won't break anything there. Thank you. commit 9dc8eaa50afa6ac88c44fbaad82509721e106f1a Author: Andriy Gapon Date: Wed Mar 6 08:57:35 2013 +0200 post mountroot event after a real/final root is mounted not every time an intermediate root (including the first devfs) is mounted. diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index 147926e..162738d 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -199,8 +199,6 @@ set_rootvnode(void) VREF(rootvnode); FILEDESC_XUNLOCK(p->p_fd); - - EVENTHANDLER_INVOKE(mountroot); } static int @@ -991,6 +989,8 @@ vfs_mountroot(void) atomic_store_rel_int(&root_mount_complete, 1); wakeup(&root_mount_complete); mtx_unlock(&mountlist_mtx); + + EVENTHANDLER_INVOKE(mountroot); } static struct mntarg * -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 20 18:43:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C57CEACE; Wed, 20 Mar 2013 18:43:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A49D9D2B; Wed, 20 Mar 2013 18:43:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D5F99B939; Wed, 20 Mar 2013 14:43:55 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: mountroot event Date: Wed, 20 Mar 2013 09:30:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514973A3.9030706@FreeBSD.org> In-Reply-To: <514973A3.9030706@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303200930.01080.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Mar 2013 14:43:55 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:43:56 -0000 On Wednesday, March 20, 2013 4:30:27 am Andriy Gapon wrote: > > I would like to propose the following change. > > My understanding is that it was never a true intention to post 'mountroot' event > on every set_rootvnode() call, but rather an accident in the original commit. > But I could be wrong here. In either case I think that it is more appropriate > to post the event only once. I do not expect that there could be any consumers > interested in all the details of root fs manipulations. The firmware code only needs the final call for the "real" root. I think your change is fine. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 21 15:48:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DD2E7B8 for ; Thu, 21 Mar 2013 15:48:20 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from eu.route.mx (eu.route.mx [46.137.95.40]) by mx1.freebsd.org (Postfix) with ESMTP id A3813345 for ; Thu, 21 Mar 2013 15:48:19 +0000 (UTC) Received: (route-mx 36007 invoked from network); 21 Mar 2013 15:41:36 -0000 Received: from unknown (HELO nbari-z200.diz.la) (nbari@inbox.im@[194.65.5.235]) (envelope-sender ) by eu.route.mx (route-mx) with SMTP for ; 21 Mar 2013 15:41:36 -0000 Message-ID: <514B2A2F.3040209@inbox.im> Date: Thu, 21 Mar 2013 15:41:35 +0000 From: Nicolas de Bari Embriz Garcia Rojas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: netstat -ib Obytes not incrementing on alias Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:48:20 -0000 I have 5 alias on a bce0 interface, IP's belong to another network and using mask /29 when I run the netstat -ib command I only see the Ibytes but Obytes don't increment, in contrast a lo1 (cloned interface) does show Ibytes and Obytes. Any idea or explanation of why netstat -ib don't show the Obytes for the aliased IP's on the main nic (bce0) regards From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 21 18:48:40 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E658841B for ; Thu, 21 Mar 2013 18:48:40 +0000 (UTC) (envelope-from kaltheat@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id D5108329 for ; Thu, 21 Mar 2013 18:48:40 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent:sender; b=PLnfmCK6I+vhhLnHzg0jxh1MhyEslTQGMRnd9BBxRH/DqXGBCVwZZ2Zlf5xfnqUcdlgNhFGvCAEJ lOhh9vK+HujjUbMB5AQHNRv3AlIT/i7LKNinBlJs0pXm3pZxflkE Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1363891714410150.44632937307915; Thu, 21 Mar 2013 11:48:34 -0700 (PDT) Received: from [86.103.147.236] by mail.zoho.com with HTTP;Thu, 21 Mar 2013 11:48:34 -0700 (PDT) Date: Thu, 21 Mar 2013 19:48:34 +0100 From: kaltheat To: Message-ID: <1231719416.448222.1363891714362.JavaMail.sas1@[172.29.251.236]> In-Reply-To: <20130319220625.GB5368@sol> References: <20130319220625.GB5368@sol> Subject: Fwd: Intel microcode update MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Sender: kaltheat@zoho.com X-Mailman-Approved-At: Thu, 21 Mar 2013 19:50:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:48:41 -0000 Hopefully some hacker could help me ... ============ Forwarded message ============ >From : kaltheat@googlemail.com To : Date : Tue, 19 Mar 2013 23:06:25 +0100 Subject : Intel microcode update ============ Forwarded message ============ Hi, I was wondering how to update microcode of an Intel CPU and came across cpucontrol and sysutils/devcpu-data . But last mentioned port is not up-to-date anymore. I searched Intel's webpages for microcode updates and found archives for Linux containing one single microcode.dat file. Could someone tell me if that file is compatible with FreeBSD? As devcpu-data installs .fw files it might be proper to convert/compile microcode.dat in some way. How? Regards, kaltheat From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 22 08:09:24 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFEBCFAD for ; Fri, 22 Mar 2013 08:09:24 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (mail.yamagi.org [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 627F8AD2 for ; Fri, 22 Mar 2013 08:09:24 +0000 (UTC) Received: from lennart-ws.pwag-local.de (unknown [212.48.125.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 31C7B1666312; Fri, 22 Mar 2013 09:09:22 +0100 (CET) Date: Fri, 22 Mar 2013 09:09:22 +0100 From: Yamagi Burmeister To: kaltheat@googlemail.com Subject: Re: Fwd: Intel microcode update Message-Id: <20130322090922.6d383a7e8aa515d06851e650@yamagi.org> In-Reply-To: <1231719416.448222.1363891714362.JavaMail.sas1@[172.29.251.236]> References: <20130319220625.GB5368@sol> <1231719416.448222.1363891714362.JavaMail.sas1@[172.29.251.236]> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__22_Mar_2013_09_09_22_+0100_aInbnk7+YWOIAfP_" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:09:24 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__22_Mar_2013_09_09_22_+0100_aInbnk7+YWOIAfP_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, yes the microcode file provided by Intel is incompatible with FreeBSD. You'll need to split it into individual files for each CPU. I vaguely remeber that there was a script or something like that bundled with one of the ports. Nevertheless attached is a small C program which does the same. It's not written by me, I just found it somewhere on the web. Ciao, Yamagi On Thu, 21 Mar 2013 19:48:34 +0100 kaltheat wrote: > > Hopefully some hacker could help me ... > > ============ Forwarded message ============ > >From : kaltheat@googlemail.com > To : > Date : Tue, 19 Mar 2013 23:06:25 +0100 > Subject : Intel microcode update > ============ Forwarded message ============ > > > Hi, > > I was wondering how to update microcode of an Intel CPU and came across > cpucontrol and sysutils/devcpu-data . But last mentioned port is not up-to-date > anymore. I searched Intel's webpages for microcode updates and found archives > for Linux containing one single microcode.dat file. Could someone tell me if > that file is compatible with FreeBSD? As devcpu-data installs .fw files it > might be proper to convert/compile microcode.dat in some way. How? > > Regards, > kaltheat > > > _______________________________________________ > 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" > -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Multipart=_Fri__22_Mar_2013_09_09_22_+0100_aInbnk7+YWOIAfP_-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 22 08:13:52 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A88C11C7 for ; Fri, 22 Mar 2013 08:13:52 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (mail.yamagi.org [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 7115DB19 for ; Fri, 22 Mar 2013 08:13:52 +0000 (UTC) Received: from lennart-ws.pwag-local.de (unknown [212.48.125.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 522351666313; Fri, 22 Mar 2013 09:13:50 +0100 (CET) Date: Fri, 22 Mar 2013 09:13:50 +0100 From: Yamagi Burmeister To: kaltheat@googlemail.com Subject: Re: Fwd: Intel microcode update Message-Id: <20130322091350.a7109f9b922ee4bc44f6362b@yamagi.org> In-Reply-To: <20130322090922.6d383a7e8aa515d06851e650@yamagi.org> References: <20130319220625.GB5368@sol> <1231719416.448222.1363891714362.JavaMail.sas1@[172.29.251.236]> <20130322090922.6d383a7e8aa515d06851e650@yamagi.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:13:52 -0000 On Fri, 22 Mar 2013 09:09:22 +0100 Yamagi Burmeister wrote: > Nevertheless attached is a small C program which does the > same. It's not written by me, I just found it somewhere on the web. And it was eaten my the list. You can find it here: http://deponie.yamagi.org/freebsd/misc/microdecode.c -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 22 19:09:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC76BFC3 for ; Fri, 22 Mar 2013 19:09:54 +0000 (UTC) (envelope-from vasanth.raonaik@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE72CFD for ; Fri, 22 Mar 2013 19:09:54 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so7993587lab.18 for ; Fri, 22 Mar 2013 12:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=WP/Hsnn5jNV11Ywya9u2VMmCdDApIIJC0Dt4lwTlCzc=; b=iYhRy01Bad9b57BDvg4PwPQCNOGxytoCiXRhfs26bIgvhl4syUaEifzPqryfAEbPoA 3ytZxzOPKoVOIgcOe1Gxq0ydf+H7gydZFEyPFiYWPHXrYOM4iKbF4kC59LIbcH96hKdo Kz2lrKMkmmRdHNvQbDfeRwsb529tnv5Qj4Chz56pVRHgFIjRAZ9FszTv6mINQs74DBLx ZFB10Q1/OFXnH6ffodSd8ltfuYAN436hmnvvbW5ucYo0a246gE7Nk/L2WcM7h26nTxtl VnMsli+f9cwNeMDSiuLiIa2JU6rGjM54rGwe15kkqB8wtmDPY7AHaE0q7xtPgKiMYy8I l+NA== MIME-Version: 1.0 X-Received: by 10.112.48.39 with SMTP id i7mr1637769lbn.129.1363979393303; Fri, 22 Mar 2013 12:09:53 -0700 (PDT) Received: by 10.112.138.33 with HTTP; Fri, 22 Mar 2013 12:09:53 -0700 (PDT) Date: Fri, 22 Mar 2013 15:09:53 -0400 Message-ID: Subject: preemptive kernel From: vasanth rao naik sabavat To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:09:54 -0000 Hi, Is the FreeBSD-10 kernel preemptive? -- Thanks, Vasanth From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 22 20:00:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 28D78DB8 for ; Fri, 22 Mar 2013 20:00:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id BCF7F1C0 for ; Fri, 22 Mar 2013 20:00:49 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id u50so2573301wey.3 for ; Fri, 22 Mar 2013 13:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QbBVcJlCESNw7vEznGRarP3tfA42z+jS1QOcx8Y4LGM=; b=VQbvzxIKASh5HzQxC66cN8eOgdh8w6m2aPSCgg/nz3Peu624dA/1CS1vEAxU33FD2f BULWCwXHZAZ3bFu60HokTePopUNPvgnM9J1LR8G4WuRwP6+ulnSiV/4Y/ptsmT4c6Sd7 eCTaM8KSTXt6Q3bWXdysoyE8KKuHwc+v0EuVDZDhVoJUiBjJeRUkH4s6t2+TkKKXlPam gQzB6A6pSa/kNz4WJXaYFJxkfRrUWXQlqtAvD1KkiDl4T9dPQmH4SNbZU0m0lCLsymWA WB8REJgZYeeSk+7frThqEviYh4XY5dB6OfchKrA7UFICsXHHxVn2pDAJiTHWcRMXdL7U 6mTQ== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr5488426wje.5.1363982448979; Fri, 22 Mar 2013 13:00:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 22 Mar 2013 13:00:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 13:00:48 -0700 X-Google-Sender-Auth: iJPh_lZ5_dhTN5IbchPq6is2J8Q Message-ID: Subject: Re: preemptive kernel From: Adrian Chadd To: vasanth rao naik sabavat Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 20:00:50 -0000 Yes. Adrian On 22 March 2013 12:09, vasanth rao naik sabavat wrote: > Hi, > > Is the FreeBSD-10 kernel preemptive? > > -- > Thanks, > Vasanth > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 22 20:10:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 43D82470; Fri, 22 Mar 2013 20:10:18 +0000 (UTC) (envelope-from vasanth.raonaik@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3D3277; Fri, 22 Mar 2013 20:10:17 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id fe20so8097958lab.15 for ; Fri, 22 Mar 2013 13:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1Bn32o8O6eFVPWFTDP5z2r1pFiVEEQo1+4+08fyeZVE=; b=nygzLxGeVIiKK8z4aueYWfobqqrRi1J72n5qH+3jXABKuwJ/G1wXvNOhtUzXi/eFIZ OUyWfAoa4qfgEBXb6g7/G8mQkdgmdU/KzDlRt2smqcIUcoy4qIJN39RZJo0pz9Hpcttd uSYUiTf1pXOYGsFfJG/noIVtstUbUf9IvB3DgPJ1UvfgMrKT/k/BOMKmqS8N2BtkSk4B QKoDOThalgK61gvyYSTiqCnbV95buZvcS5qPV9d9Qt1JyUJH6AAUm4VDUDiFJu49bZe8 MqnoQVGpgpujtBUurfiAqXHs4KpkqIzjy8+JbKrkmb+6blsVmuaieZSwzK8ZYnyUjBgN 2f2A== MIME-Version: 1.0 X-Received: by 10.112.49.3 with SMTP id q3mr1826828lbn.92.1363983016563; Fri, 22 Mar 2013 13:10:16 -0700 (PDT) Received: by 10.112.138.33 with HTTP; Fri, 22 Mar 2013 13:10:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 16:10:16 -0400 Message-ID: Subject: Re: preemptive kernel From: vasanth rao naik sabavat To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 20:10:18 -0000 Hi Adrian, Just to clarify, is the kernel pre-emption involuntary? Let say I have a kernel thread processing a huge list of entries, would this thread get involuntarily context switched out because of kernel preemption? What is the time slice after which a kernel thread can involuntarily context switched out? Could you please point to the file in the source code which handles the kernel pre-emption. Thanks, Vasanth On Fri, Mar 22, 2013 at 4:00 PM, Adrian Chadd wrote: > Yes. > > > > Adrian > > > On 22 March 2013 12:09, vasanth rao naik sabavat > wrote: > > Hi, > > > > Is the FreeBSD-10 kernel preemptive? > > > > -- > > Thanks, > > Vasanth > > _______________________________________________ > > 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" > -- Thanks, Vasanth From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 23 09:48:56 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1BC84BFD; Sat, 23 Mar 2013 09:48:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8C2FD32; Sat, 23 Mar 2013 09:48:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA15528; Sat, 23 Mar 2013 11:48:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UJL4G-000Dtf-O0; Sat, 23 Mar 2013 11:48:52 +0200 Message-ID: <514D7A82.9000105@FreeBSD.org> Date: Sat, 23 Mar 2013 11:48:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> In-Reply-To: <5114AB2E.2050909@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 09:48:56 -0000 Looks like this issue needs more thinking and discussing. The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on SMP systems). This is for exactly the same reasons as to why we first take smp_ipi_mtx before calling stop_cpus() in the shutdown path. Essentially one CPU could be holding smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), while another CPU could be with interrupts disabled (explicitly - like in the shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a deadlock is quite possible. Some obstacles for just going ahead and making the suggested change: - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we would have to make intr_table_lock and msi_lock the spin-locks as well; - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and currently it performs an action that requires memory allocation; again, with interrupts disabled via intr_disable() this fact is not visible to witness, etc, but with smp_ipi_mtx it needs to be somehow handled. I talked to ACPICA guys about the last issue and they told me that what is currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and _GTS support was removed. What do you think? Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 23 09:54:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A8A1EC7 for ; Sat, 23 Mar 2013 09:54:20 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 221B3D76 for ; Sat, 23 Mar 2013 09:54:19 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 9981A86179 for ; Sat, 23 Mar 2013 10:54:18 +0100 (CET) Message-ID: <514D7BC9.2020607@bsdforen.de> Date: Sat, 23 Mar 2013 10:54:17 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: bsdgrep status X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 09:54:20 -0000 In 2011 I substituted grep for bsdgrep in some of my more complex shell scripts and ran into some issues. Though there never was a reply to my e-mail these issues have evidently been fixed. I'm tempted to conclude that bsdgrep is ready for deployment. Apart from the performance standpoint. I repeated the following several times the result is always about the same: # time -h pkg_libchk.gnu eclipse-3.7.1_4: /usr/local/lib/eclipse/configuration/org.eclipse.osgi/bundles/119/1/.cp/libswt-awt-gtk-3738.so misses libjawt.so libreoffice-4.0.1: /usr/local/lib/libreoffice/program/xpdfimport misses libpoppler.so.18 18m7.13s real 4m49.19s user 20m54.07s sys # time -h pkg_libchk.bsd eclipse-3.7.1_4: /usr/local/lib/eclipse/configuration/org.eclipse.osgi/bundles/119/1/.cp/libswt-awt-gtk-3738.so misses libjawt.so libreoffice-4.0.1: /usr/local/lib/libreoffice/program/xpdfimport misses libpoppler.so.18 20m30.75s real 5m10.25s user 22m6.71s sys I cannot say how much of the runtime is caused by grep, but all the difference is certainly made by grep and I think the difference is significant. It's maybe not bad enough to stop the switch, however it violates the noble tradition of having command line tools that are faster than the GNU equivalents. E.g. my latest AWK script is 7 times faster using one-true-awk, compared to GNU AWK. Compare bash and ash and you'll end up with a factor around 3 for scripts that mostly use builtin commands. Regards, Kami -- 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 Sat Mar 23 09:58:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EBB3A13A for ; Sat, 23 Mar 2013 09:58:50 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7D138D9A for ; Sat, 23 Mar 2013 09:58:50 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/avgusCdtw9+43oQGYIsZZxQQ0xcmsA== X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (cl-3506.cgn-01.de.sixxs.net [IPv6:2001:4dd0:ff00:db1::2]) by smtp.strato.de (jorabe mo4) (RZmta 31.23 AUTH) with (AES128-SHA encrypted) ESMTPA id h0731ap2N9Lglf for ; Sat, 23 Mar 2013 10:58:42 +0100 (CET) Received: by britannica.bec.de (sSMTP sendmail emulation); Sat, 23 Mar 2013 18:58:41 +0900 Date: Sat, 23 Mar 2013 18:58:41 +0900 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: bsdgrep status Message-ID: <20130323095841.GA10740@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <514D7BC9.2020607@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514D7BC9.2020607@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 09:58:51 -0000 On Sat, Mar 23, 2013 at 10:54:17AM +0100, Dominic Fandrey wrote: > I'm tempted to conclude that bsdgrep is ready for deployment. There are still some issues. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 23 15:15:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BCE5B56 for ; Sat, 23 Mar 2013 15:15:02 +0000 (UTC) (envelope-from joel@vnode.se) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 118FB8DD for ; Sat, 23 Mar 2013 15:15:01 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id CFD40E3F07B for ; Sat, 23 Mar 2013 16:14:53 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmXZKa92rN0h for ; Sat, 23 Mar 2013 16:14:52 +0100 (CET) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id D1D5BE3F079 for ; Sat, 23 Mar 2013 16:14:51 +0100 (CET) Date: Sat, 23 Mar 2013 16:14:50 +0100 From: Joel Dahl To: freebsd-hackers@freebsd.org Subject: Re: bsdgrep status Message-ID: <20130323151450.GA23521@devbox.vnode.local> References: <514D7BC9.2020607@bsdforen.de> <20130323095841.GA10740@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130323095841.GA10740@britannica.bec.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:15:02 -0000 On Sat, Mar 23, 2013 at 06:58:41PM +0900, Joerg Sonnenberger wrote: > On Sat, Mar 23, 2013 at 10:54:17AM +0100, Dominic Fandrey wrote: > > I'm tempted to conclude that bsdgrep is ready for deployment. > > There are still some issues. Are these issues documented somewhere? -- Joel From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 23 15:42:23 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2BC1235E for ; Sat, 23 Mar 2013 15:42:23 +0000 (UTC) (envelope-from kaltheat@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 18D519D3 for ; Sat, 23 Mar 2013 15:42:22 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to:user-agent:sender; b=rSbTsC2B2M0ysI3x7EeQS/puaFVRKEDIEb1kuPcgBXYbCdfgcY8I4r7JFQCNZ/csHp3JrsrQ2dBZ HzNNoPLAoWnrZtoAc8IMizzqR6U0t4SWVLnbhu2lrBA2TACwnDM8 Received: from sol (121-147-103-86.dynamic.dsl.tng.de [86.103.147.121]) by mx.zohomail.com with SMTPS id 136405333585791.2730910128463; Sat, 23 Mar 2013 08:42:15 -0700 (PDT) Date: Sat, 23 Mar 2013 16:42:06 +0100 From: kaltheat@googlemail.com To: Yamagi Burmeister Subject: Re: Fwd: Intel microcode update Message-ID: <20130323154206.GA3332@sol> References: <20130319220625.GB5368@sol> <1231719416.448222.1363891714362.JavaMail.sas1@[172.29.251.236]> <20130322090922.6d383a7e8aa515d06851e650@yamagi.org> <20130322091350.a7109f9b922ee4bc44f6362b@yamagi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130322091350.a7109f9b922ee4bc44f6362b@yamagi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: kaltheat@zoho.com X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Mailman-Approved-At: Sat, 23 Mar 2013 17:37:46 +0000 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:42:23 -0000 On Fri, Mar 22, 2013 at 09:13:50AM +0100, Yamagi Burmeister wrote: > On Fri, 22 Mar 2013 09:09:22 +0100 > Yamagi Burmeister wrote: > > > Nevertheless attached is a small C program which does the > > same. It's not written by me, I just found it somewhere on the web. > > And it was eaten my the list. You can find it here: > http://deponie.yamagi.org/freebsd/misc/microdecode.c Thanks. It does decode the .dat-file . kaltheat