Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)
On Tue, 27 Jul 2010, Anton Shterenlikht wrote: On Tue, Jul 27, 2010 at 05:53:25PM +0100, Gavin Atkinson wrote: On Tue, 2010-07-27 at 15:47 +0100, Anton Shterenlikht wrote: db bt Tracing pid 0 tid 10 td 0x80b40de0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b uma_dbg_free() at uma_zfree_arg+0x62 free() at free+0xcd device_set_driver() at device_set_driver+0x7c device_attach() at device_attach+0x1a3 Thanks. Can you try http://people.freebsd.org/~gavin/mexas-hda-panic.diff and see if that solves things for you? (Credit goes to avg@ for looking into this before me :) yes, thanks, the panic has gone away. I've committed this patch, and will MFC in one week. Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] big whitespace cleanup in sys/kern/*
Hi, On 3 Aug 2010, at 18:58, Jamie Gritton wrote: I always understood that is was a style error *not* to have at least some whitespace before a label, that only top-level objects should be pushed all the way to the left column. Style(9) appears to be silent on this issue. Labels are special in that their scope is the enclosing function (not the enclosing block). Hanging them to the left emphasises this. -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Driver tpm(4) and third party packages for trusted platform modules
In message 201008040347.o743leer046...@sana.init-main.com, wrote: Quick review and hack: 1.How about attaching it as acpi child driver? In some case, TPM may appear in ACPI namespace (with _HID) and TPM spec defines ACPI method to handle TPM specific request. 2. Is identify method needed? Writing device hint will attach isa child driver, I think. 3.Module build I don't know it is proper in TPM nature. Update my patch. Split bus attachment from main driver file (need to update sys/conf/files), add detach method for convinience, and attach softc to cdev.si_drv1 . diff -ruN src/sys/dev/tpm/tpm.c src.new/sys/dev/tpm/tpm.c --- src/sys/dev/tpm/tpm.c 2010-08-04 12:39:05.0 +0900 +++ src.new/sys/dev/tpm/tpm.c 2010-08-04 19:32:44.0 +0900 @@ -49,6 +49,7 @@ #include dev/isa/isareg.h #include dev/isa/isavar.h #endif +#include tpmvar.h #ifndef __FreeBSD__ /* XXX horrible hack for tcsd (-lpthread) workaround on OpenBSD */ @@ -142,43 +143,10 @@ /* Set when enabling legacy interface in host bridge. */ int tpm_enabled; -struct tpm_softc { -#ifndef __FreeBSD__ - struct device sc_dev; -#endif - void *sc_ih; - - int (*sc_init)(struct tpm_softc *, int, const char *); - int (*sc_start)(struct tpm_softc *, int); - int (*sc_read)(struct tpm_softc *, void *, int, size_t *, int); - int (*sc_write)(struct tpm_softc *, void *, int); - int (*sc_end)(struct tpm_softc *, int, int); - - bus_space_tag_t sc_bt, sc_batm; - bus_space_handle_t sc_bh, sc_bahm; - - u_int32_t sc_devid; - u_int32_t sc_rev; - u_int32_t sc_stat; - u_int32_t sc_capabilities; - - int sc_flags; -#defineTPM_OPEN0x0001 - - int sc_vector; -#ifdef __FreeBSD__ - void*intr_cookie; -#endif - -#ifndef __FreeBSD__ - void*sc_powerhook; -#endif - int sc_suspend; -}; #ifdef __FreeBSD__ #defineTPMSOFTC(dev) \ -((struct tpm_softc *)devclass_get_softc(tpm_devclass, dev2unit(dev))) + ((struct tpm_softc *)dev-si_drv1) d_open_t tpmopen; d_close_t tpmclose; @@ -229,7 +197,6 @@ { 0, , TPM_DEV_NOINTS }, }; -int tpm_tis12_probe(bus_space_tag_t, bus_space_handle_t); int tpm_tis12_irqinit(struct tpm_softc *, int, int); int tpm_tis12_init(struct tpm_softc *, int, const char *); int tpm_tis12_start(struct tpm_softc *, int); @@ -239,8 +206,6 @@ #ifdef __FreeBSD__ void tpm_intr(void *); -int tpm_suspend(device_t); -int tpm_resume(device_t); #else int tpm_intr(void *); void tpm_powerhook(int, void *); @@ -264,67 +229,45 @@ int tpm_legacy_end(struct tpm_softc *, int, int); #ifdef __FreeBSD__ + /* * FreeBSD specific code for probing and attaching TPM to device tree. */ +#if 0 static void tpm_identify(driver_t *driver, device_t parent) { BUS_ADD_CHILD(parent, ISA_ORDER_SPECULATIVE, tpm, 0); } +#endif -static int -tpm_probe(device_t dev) -{ - struct tpm_softc *sc = device_get_softc(dev); - bus_space_tag_t iot; - bus_space_handle_t ioh; - struct resource *mem_res; - int rv, mem_rid; - - bzero(sc, sizeof(struct tpm_softc)); - - mem_rid = 0; - mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, mem_rid, - RF_ACTIVE); - if (mem_res == NULL) - return (ENXIO); - iot = rman_get_bustag(mem_res); - ioh = rman_get_bushandle(mem_res); - - if ((rv = tpm_tis12_probe(iot, ioh))) - device_set_desc(dev, Trusted Platform Module); - - bus_release_resource(dev, SYS_RES_MEMORY, mem_rid, mem_res); - return rv ? 0 : ENXIO; -} -static int +int tpm_attach(device_t dev) { struct tpm_softc *sc = device_get_softc(dev); - struct resource *mem_res; - int mem_rid; - int irq_rid, irq; - struct resource *irq_res; + int irq; - mem_rid = 0; - mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, mem_rid, + sc-mem_rid = 0; + sc-mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, sc-mem_rid, RF_ACTIVE); - if (mem_res == NULL) + if (sc-mem_res == NULL) return ENXIO; - sc-sc_bt = rman_get_bustag(mem_res); - sc-sc_bh = rman_get_bushandle(mem_res); + sc-sc_bt = rman_get_bustag(sc-mem_res); + sc-sc_bh = rman_get_bushandle(sc-mem_res); - irq_rid = 0; - irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, irq_rid, + sc-irq_rid = 0; + sc-irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, sc-irq_rid, RF_ACTIVE | RF_SHAREABLE); - if (irq_res != NULL) - irq = rman_get_start(irq_res); + if (sc-irq_res != NULL) + irq = rman_get_start(sc-irq_res); else irq = IRQUNK; + /*In case PnP probe this may contain some initialization.*/ + tpm_tis12_probe(sc-sc_bt, sc-sc_bh); + if
Re: [patch] big whitespace cleanup in sys/kern/*
On Tue, 03.08.2010 at 17:21:45 -0700, Steve Kargl wrote: On Tue, Aug 03, 2010 at 05:40:05PM -0400, Thomas Dickey wrote: On Tue, Aug 03, 2010 at 11:22:36AM -0700, Julian Elischer wrote: On 8/3/10 2:34 AM, pluknet wrote: Hi. I looked into sys/kern/* files to fix a bunch of common w/s style issues (221): - leading space before label; - leading space(s) beforetab; - space(s) instead oftab(s); - space(s) in blank like. I tried to be conservative and didn't touch semi-contrib files and those with its own style. Here is a diff I'd like someone look into and check in if there will no objections. The style guide suggests against wholesale cleanups and we have generally avoided them due to teh fact that they tend to obfuscate diffs. The idea being that we clean as we go.. however it may be time for one.. I'd leave it to others to decide. I'm curious why there's no mention of using 'indent' (with appropriate settings...). Because there is no set of appropriate settings for indent(1) to reproduce style(9). uncrustify (in ports) can be made to almost adhere to style(9). The documentation/configuration of that tool is horrible, though. I someone is interested in my uncrustify.cfg and wants to improve it, drop me a line. Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On 08/03/2010 14:21, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. This is a common functionality gnu-grep. tail -f never exits and grep keeps grepping until it gets a EOF which is never hit unless you ^C. A good example for such a use is monitoring a all.log log while looking for non-exact situations. something like % tail -f all.log |egrep -v (sendmail|sm-mta|cron) which would remove all lines that contain sendmail sm-mta cron from the output and continue to read output from tail -f until it is ^C. You can turn on your all.log through /etc/syslog.conf after creating the mode 600 file under /var/log for toying with. There is quite a few other cases but I don't think I need to mention them. I rely on this for continuous firewall log trolling. No offense but If the functionality exists in gnu-grep then the same functionality needs to exist in bsd-grep, ``period''. At least for the mean-time. Regards, -- jhell,v ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Incorrect cv_wait_sig() return values?
Hi, I recently noticed that cv_wait_sig() will return -1 rather than EINTR when a SIGINT is delivered. This is in contrast to CONDVAR(9) which states: ... cv_wait_sig() and cv_timedwait_sig() return prematurely with a value of EINTR or ERESTART if a signal is caught ... To demonstrate the problem outside my out-of-tree driver, I took the skeleton driver from http://www.captain.at/programming/freebsd/ and added the following function, invoked at module load: static struct mtx m; static struct cv c; static void cv_test(void) { int rc; mtx_init(m, skel_m, MTX_DEF, MTX_DEF); cv_init(c, skel_c); mtx_lock(m); rc = cv_wait_sig(c, m); mtx_unlock(m); printf(cv_wait_sig returned %d\n, rc); cv_destroy(c); mtx_destroy(m); } I load the module, and I ^C kldload after a few seconds to break out of the cv_wait_sig(), which results in this output on console: Skeleton KLD loaded. cv_wait_sig returned -1 Am I doing something wrong, or are condvars broken? I've tried to track this down with dtrace, but failed.. Thanks, Drew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I am not sure it is specific to the GNU grep -- below is the example from AIX 5.3: su...@irptdev_1tail -f engine.log | grep Hello Aug 4 10:41:39 irptdev_1 local3:debug sunny: Hello Wed Aug 4 10:41:39 EDT 2010 Aug 4 10:41:46 irptdev_1 local3:debug sunny: Hello Wed Aug 4 10:41:46 EDT 2010 Aug 4 10:41:57 irptdev_1 local3:debug sunny: Hello Wed Aug 4 10:41:57 EDT 2010 I am doing su...@irptdev_1logger -p local3.debug Hello `date` su...@irptdev_1logger -p local3.debug Hello `date` su...@irptdev_1logger -p local3.debug Hello `date` from different terminal window. HTH, -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Making email access easy http://mail.ovi.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Incorrect cv_wait_sig() return values?
On Wed, Aug 04, 2010 at 10:36:24AM -0400, Andrew Gallatin wrote: Hi, I recently noticed that cv_wait_sig() will return -1 rather than EINTR when a SIGINT is delivered. This is in contrast to CONDVAR(9) which states: ... cv_wait_sig() and cv_timedwait_sig() return prematurely with a value of EINTR or ERESTART if a signal is caught ... To demonstrate the problem outside my out-of-tree driver, I took the skeleton driver from http://www.captain.at/programming/freebsd/ and added the following function, invoked at module load: static struct mtx m; static struct cv c; static void cv_test(void) { int rc; mtx_init(m, skel_m, MTX_DEF, MTX_DEF); cv_init(c, skel_c); mtx_lock(m); rc = cv_wait_sig(c, m); mtx_unlock(m); printf(cv_wait_sig returned %d\n, rc); cv_destroy(c); mtx_destroy(m); } I load the module, and I ^C kldload after a few seconds to break out of the cv_wait_sig(), which results in this output on console: Skeleton KLD loaded. cv_wait_sig returned -1 Am I doing something wrong, or are condvars broken? I've tried to track this down with dtrace, but failed.. What version of the system do you use ? I cannot confirm this on the HEAD from several hours ago with the following test module. On the SIGINT I get `4' printed, which is EINTR. #include sys/param.h #include sys/systm.h #include sys/kernel.h #include sys/lock.h #include sys/module.h #include sys/mutex.h #include sys/condvar.h static struct mtx m; static struct cv c; static void cv_test(void) { int rc; mtx_init(m, skel_m, MTX_DEF, MTX_DEF); cv_init(c, skel_c); mtx_lock(m); rc = cv_wait_sig(c, m); mtx_unlock(m); printf(cv_wait_sig returned %d\n, rc); cv_destroy(c); mtx_destroy(m); } static int test_load(module_t mod, int cmd, void *arg) { switch (cmd) { case MOD_LOAD: cv_test(); break; } return (0); } static moduledata_t test_module = { test, test_load, NULL }; DECLARE_MODULE(test, test_module, SI_SUB_KLD, SI_ORDER_FIRST); MODULE_VERSION(test, 1); pgpz2cxfxk5ZS.pgp Description: PGP signature
Re: Incorrect cv_wait_sig() return values?
On Wed, Aug 04, 2010 at 06:46:04PM +0300, Kostik Belousov wrote: On Wed, Aug 04, 2010 at 10:36:24AM -0400, Andrew Gallatin wrote: Hi, I recently noticed that cv_wait_sig() will return -1 rather than EINTR when a SIGINT is delivered. This is in contrast to CONDVAR(9) which states: ... cv_wait_sig() and cv_timedwait_sig() return prematurely with a value of EINTR or ERESTART if a signal is caught ... To demonstrate the problem outside my out-of-tree driver, I took the skeleton driver from http://www.captain.at/programming/freebsd/ and added the following function, invoked at module load: static struct mtx m; static struct cv c; static void cv_test(void) { int rc; mtx_init(m, skel_m, MTX_DEF, MTX_DEF); cv_init(c, skel_c); mtx_lock(m); rc = cv_wait_sig(c, m); mtx_unlock(m); printf(cv_wait_sig returned %d\n, rc); cv_destroy(c); mtx_destroy(m); } I load the module, and I ^C kldload after a few seconds to break out of the cv_wait_sig(), which results in this output on console: Skeleton KLD loaded. cv_wait_sig returned -1 Am I doing something wrong, or are condvars broken? I've tried to track this down with dtrace, but failed.. What version of the system do you use ? I cannot confirm this on the HEAD from several hours ago with the following test module. On the SIGINT I get `4' printed, which is EINTR. BTW, -1 is ERESTART, so if you have SIGINT catched with SA_RESTART flag in the process that initiated kldload(2) syscall, then -1 is the right return code for cv_wait_sig. pgp9l3SKbjafV.pgp Description: PGP signature
Re: Incorrect cv_wait_sig() return values?
Kostik Belousov wrote: BTW, -1 is ERESTART, so if you have SIGINT catched with SA_RESTART flag in the process that initiated kldload(2) syscall, then -1 is the right return code for cv_wait_sig. Ah, makes sense. I hadn't considered that a BSD kernel error could be negative. I should have actually looked at errno.h. Sorry for the noise, and thanks for the explanation. Drew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote: On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I am not sure it is specific to the GNU grep -- below is the example from AIX 5.3: [...] Same on Solaris, so this is not a GNU feature. pgpGldYyM2bSl.pgp Description: PGP signature
Re: bsdgrep does not work with tail -f | grep combination
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote: On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote: On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I am not sure it is specific to the GNU grep -- below is the example from AIX 5.3: [...] Same on Solaris, so this is not a GNU feature. Why is bsdgrep reading the whole file before processing, anyway? It seems like line-by-line processing would be the way to go. Erik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote: On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote: On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I am not sure it is specific to the GNU grep -- below is the example from AIX 5.3: [...] Same on Solaris, so this is not a GNU feature. Just to clarify things, bsdgrep of course works with tail -f, the data just sits in its buffer: ~ jot 10 test ~ tail -f test | grep 0 [on another terminal] ~ jot 10 test [nothing happens on original terminal] ~ jot 4000 test [on the original terminal] 10 10 10 20 30 40 50 60 70 80 90 100 101 102 103 [snip] 3950 3960 3970 3980 3990 4000 Alexey. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On 4 August 2010 20:28, Lars Engels lars.eng...@0x20.net wrote: On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote: On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I am not sure it is specific to the GNU grep -- below is the example from AIX 5.3: [...] Same on Solaris, so this is not a GNU feature. By the way, egrep from 4.4BSD-Alpha used read(2) with 8k blocks. I justed checked, it works with tail -f. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On Tue, 3 Aug 2010, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. On 8.1, GNU grep (from system) and FreeGrep (personal repo with my fastcomp changes) both output the '10' from this test. Are you sure you ran GNU grep on that system and did not accidentally run a copy of BSD grep? With bsdgrep in HEAD, I think it is not processing the input until stdio's buffer is flushed at the 8KB mark. I barely looked at the code, so I am merely surmising. Sean -- s...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/08/03 11:21, Gabor Kovesdan wrote: I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I'm able to reproduce the GNU behavior on 9.0-CURRENT which is IMO right. I think we need to break at the line end to provide better interactivity (the current code seems to do it (buffer is not full !eof), while what we wanted is (buffer is not full !eof !eol). The attached patch should fix this but I have not yet thoroughly tested it due to job work. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMWawXAAoJEATO+BI/yjfBigMIAM2PHLXm2Qz4Kzhd8y+NYc2S VKJVzNv6DAVMyqCXbezp6d+Qt4sls31uvFhizS9e6HZdUolqV4/m5AiM9UcF2wK4 i49PoQPSBs3Gpp0fuM4kxlZCp843ABkZfeYr2oFZluEA144jlA2bwrX598hmo2Ge ikpljC/4R8e6TOdTNobcV4jTeHCcGYZv5nmCmODY4DZoGkFjXNQJL/zpHLYgaNyn 0j9TZ1okhaG/jLATlc+UhtyetB/wkN8VGNDyxQNg4a7iMw0xkqjoxMVpsoF4uoXS YOcSEOXuvwHxs6jlkH7z0u06bmqqdv7Okw4OSANvGN35AuB7OQDrJWHdPBS9DZA= =pZe0 -END PGP SIGNATURE- Index: file.c === --- file.c (revision 210851) +++ file.c (working copy) @@ -139,7 +139,7 @@ while (i bufsiz) { ch = grep_fgetc(f); - if (ch == EOF) + if (ch == EOF || ch == '\n') break; binbuf[i++] = ch; } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On Tue, 03 Aug 2010 20:21:56 +0200 Gabor Kovesdan ga...@freebsd.org wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. This is more fundamental, not just limited to grep. tail -f never closes its stdout channel so the next process in the pipeline will never seen an EOF on its stdin and must continue processing its input. Try this: rm -f /tmp/1; touch /tmp/1 tail -f /tmp/1 | cat while sleep 1; do date /tmp/1; done Notice how cat doesn't quit. In fact tail -f /tmp/1 | bsdgrep '' must behave exactly the same as tail -f /tmp/1 | cat and so must this: tail -f /tmp/1 | cat | bsdgrep '' bsdgrep when used this way doesn't quit but doesn't do anything either (including printing what tail -f spits out from existing file data). This is just a bug. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Driver tpm(4) and third party packages for trusted platform modules
Hi, On Wed, Aug 04, 2010 at 07:39:41PM +0900, Takanori Watanabe wrote: In message 201008040347.o743leer046...@sana.init-main.com, wrote: Quick review and hack: 1.How about attaching it as acpi child driver? In some case, TPM may appear in ACPI namespace (with _HID) and TPM spec defines ACPI method to handle TPM specific request. 2. Is identify method needed? Writing device hint will attach isa child driver, I think. 3.Module build I don't know it is proper in TPM nature. With respect to using a TPM as a PKCS#11 token for eg. ssh using a module for the driver seems ok to me. Update my patch. Split bus attachment from main driver file (need to update sys/conf/files), add detach method for convinience, and attach softc to cdev.si_drv1 . many thanks for your feedback! I will try to integrate your diff tomorrow. Regards, HJ. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
Em 2010.08.04. 20:06, Xin LI escreveu: I'm able to reproduce the GNU behavior on 9.0-CURRENT which is IMO right. I think we need to break at the line end to provide better interactivity (the current code seems to do it (buffer is not full !eof), while what we wanted is (buffer is not full !eof !eol). The attached patch should fix this but I have not yet thoroughly tested it due to job work. I think the patch may break binary detection. That buffer is not a general buffer but filled in only once with the first n bytes of the file to check if the file is binary. If you stop after the first line, only the first line will be used for binary checking. I'll look at this problem soon. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdgrep does not work with tail -f | grep combination
On 08/04/10 11:18, Bakul Shah wrote: bsdgrep when used this way doesn't quit but doesn't do anything either (including printing what tail -f spits out from existing file data). Does adding --line-buffered to the grep command line change the behavior at all? -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org