From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 881D121A07A82 for ; Fri, 8 Feb 2019 16:40:21 -0800 (PST) Received: by mail-ot1-x344.google.com with SMTP id a11so8909747otr.10 for ; Fri, 08 Feb 2019 16:40:21 -0800 (PST) MIME-Version: 1.0 References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> <20181206153718.GD24603@bombadil.infradead.org> <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> <20181211094140.2a928fe7@gandalf.local.home> <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> In-Reply-To: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> From: Brendan Higgins Date: Fri, 8 Feb 2019 16:40:08 -0800 Message-ID: Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Anton Ivanov Cc: brakmo@fb.com, Knut Omang , jeffm@suse.com, dri-devel@lists.freedesktop.org, Sasha Levin , Linux Trace Devel , linux-kselftest@vger.kernel.org, Frank Rowand , Rob Herring , linux-nvdimm@lists.01.org, mpe@ellerman.id.au, Eric Sandeen , Kieran Bingham , Matthew Wilcox , Felix Guo , Joel Stanley , jdike@addtoit.com, Petr Mladek , shuah@kernel.org, Tim.Bird@sony.com, Kees Cook , linux-um@lists.infradead.org, Steven Rostedt , Julia Lawall , kunit-dev@googlegroups.com, Greg KH , Linux Kernel Mailing List , Kent Overstreet , Luis Chamberlain , Eryu Guan , Daniel Vetter , richard@nod.at, joe@perches.com, linux-fsdevel@vger.kernel.org, khilman@baylibre.com List-ID: On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov wrote: > > > On 12/11/18 2:41 PM, Steven Rostedt wrote: > > On Tue, 11 Dec 2018 15:09:26 +0100 > > Petr Mladek wrote: > > > >>> We have liburcu already, which is good. The main sticking points are: > >>> > >>> - printk has started adding a lot of %pX enhancements which printf > >>> obviously doesn't know about. > >> I wonder how big problem it is and if it is worth using another > >> approach. > > No, please do not change the %pX approach. > > > >> An alternative would be to replace them with helper functions > >> the would produce the same string. The meaning would be easier > >> to understand. But concatenating with the surrounding text > >> would be less elegant. People might start using pr_cont() > >> that is problematic (mixed lines). > >> > >> Also the %pX formats are mostly used to print context of some > >> structures. Even the helper functions would need some maintenance > >> to keep them compatible. > >> > >> BTW: The printk() feature has been introduced 10 years ago by > >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure > >> support for extended '%p' specifiers"). > > trace-cmd and perf know about most of the %pX data and how to read it. > > Perhaps we can extend the libtraceevent library to export a generic way > > to read data from printk() output for other tools to use. > > Going back for a second to using UML for this. UML console at present is > interrupt driven - it emulates serial IO using several different > back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on > the host side are used to trigger the UML interrupts - both read and write. > > This works OK for normal use, but may result in all kinds of interesting > false positives/false negatives when UML is used to run unit tests > against a change which changes interrupt behavior. > > IMO it may be useful to consider some alternatives specifically for unit > test coverage purposes where printk and/or the whole console output > altogether bypass some of the IRQ driven semantics. Whoops, sorry, didn't see your comment before I went on vacation. I completely agree. It is also annoying when trying to test other really low level parts of the kernel. I would really like to get KUnit to the point where it does not have any dependencies on anything in the kernel, but that is very challenging for many reasons. This loosely relates to what Luis, myself, and others have talked about in other threads about having a stricter notion of code dependencies in the kernel. Thinking about it now, I suspect it might be easier to limit KUnit's dependency on kernel infrastructure first; that could kind of motivate the later work. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3756DC169C4 for ; Sat, 9 Feb 2019 00:40:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 065B020844 for ; Sat, 9 Feb 2019 00:40:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="V9RzXgcO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727284AbfBIAkW (ORCPT ); Fri, 8 Feb 2019 19:40:22 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:39746 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726892AbfBIAkV (ORCPT ); Fri, 8 Feb 2019 19:40:21 -0500 Received: by mail-ot1-f65.google.com with SMTP id n8so8928418otl.6 for ; Fri, 08 Feb 2019 16:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0w3Ukbs+RXQR7C9N95F48Zuxzzs5y+qN9AJE71LlehA=; b=V9RzXgcODcZdIhljMasYD7/kAPjEMdyucO1l6yTbIcevkoNPrxAEeDb9POCViuOTh5 cWhtLsQCmr8FbZHRoy7J+a3HzOBVPOAMtTqIGA05SFiaMHj5UX90JZVsWVnMrI0tIvm9 AElqeJm+39TJ+/oPIjEA6vnM56hn6QKjE8rQaENhlI0SDZAn4dVKZ3zwH1bwQ21Ne2nd seEeolqbd3TXkA753po4l+cXpims2IVooKWeEqPVxv8d/lUTcOwbRdz8i3YJ+pzCLXa2 zO6JKm2qUZ8AkfyFzRFyeVzIhrvCp7HO5KAZE58lwUw5qcb07van8X+8QHydJnAV9XgI nlcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0w3Ukbs+RXQR7C9N95F48Zuxzzs5y+qN9AJE71LlehA=; b=GwF0MFeXbR0KrdetnLeuERLR5nvT29AcIGUWiT/vazXAih3IlFWsyZ8p6tGrQWYk2b pEFS+uMlKpYzB3JjUnS81FHJxjdveP/GYEQtkNX1F3lh/eYRMqMjU6rw/cCkUHAx8jkI V2aa18IQuIg+on5g4taxCbuL5CkySJrKLm1pgjwW2NwVv4Q04D7qiXIAjT24NxE/iwKz 4ms5BfY2qHDLbHDqZmG1M8jnI4osmUcGIN95uMyX+gdj2fKJpQLzINSsyaRKWpPuygGD +wcI31MnOFV5pdbn1HSC+SrIM2NzcsxI9j1S+P8j8vv+FfSRGiJ8BFS4qi2sip2pBBsx o7qQ== X-Gm-Message-State: AHQUAuatRSZUhfbBSmnlEOXBCdr8lCCus+6be/9iSHujAsaqNHjr00mA I+jPzW/f0suL3pTU5FupNoudXZiSkrtLJOE0841Suw== X-Google-Smtp-Source: AHgI3IZ84Za4K9rvAjg0gu0mOFc8BJC6Qu9hsEOKfDL06SIIr9xF7+Z0i2QYx7pD57IZtneYPjhR3j/H+WKpVunXcds= X-Received: by 2002:a9d:6398:: with SMTP id w24mr4926405otk.364.1549672819885; Fri, 08 Feb 2019 16:40:19 -0800 (PST) MIME-Version: 1.0 References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> <20181206153718.GD24603@bombadil.infradead.org> <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> <20181211094140.2a928fe7@gandalf.local.home> <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> In-Reply-To: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> From: Brendan Higgins Date: Fri, 8 Feb 2019 16:40:08 -0800 Message-ID: Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel To: Anton Ivanov Cc: Steven Rostedt , Petr Mladek , brakmo@fb.com, Knut Omang , jeffm@suse.com, dri-devel@lists.freedesktop.org, Sasha Levin , Linux Trace Devel , linux-kselftest@vger.kernel.org, shuah@kernel.org, Rob Herring , Frank Rowand , linux-nvdimm@lists.01.org, mpe@ellerman.id.au, Eric Sandeen , Kieran Bingham , Matthew Wilcox , Felix Guo , Joel Stanley , Kent Overstreet , jdike@addtoit.com, Tim.Bird@sony.com, linux-um@lists.infradead.org, Julia Lawall , dan.j.williams@intel.com, kunit-dev@googlegroups.com, richard@nod.at, Greg KH , Linux Kernel Mailing List , Luis Chamberlain , Eryu Guan , Daniel Vetter , Kees Cook , joe@perches.com, linux-fsdevel@vger.kernel.org, khilman@baylibre.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov wrote: > > > On 12/11/18 2:41 PM, Steven Rostedt wrote: > > On Tue, 11 Dec 2018 15:09:26 +0100 > > Petr Mladek wrote: > > > >>> We have liburcu already, which is good. The main sticking points are: > >>> > >>> - printk has started adding a lot of %pX enhancements which printf > >>> obviously doesn't know about. > >> I wonder how big problem it is and if it is worth using another > >> approach. > > No, please do not change the %pX approach. > > > >> An alternative would be to replace them with helper functions > >> the would produce the same string. The meaning would be easier > >> to understand. But concatenating with the surrounding text > >> would be less elegant. People might start using pr_cont() > >> that is problematic (mixed lines). > >> > >> Also the %pX formats are mostly used to print context of some > >> structures. Even the helper functions would need some maintenance > >> to keep them compatible. > >> > >> BTW: The printk() feature has been introduced 10 years ago by > >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure > >> support for extended '%p' specifiers"). > > trace-cmd and perf know about most of the %pX data and how to read it. > > Perhaps we can extend the libtraceevent library to export a generic way > > to read data from printk() output for other tools to use. > > Going back for a second to using UML for this. UML console at present is > interrupt driven - it emulates serial IO using several different > back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on > the host side are used to trigger the UML interrupts - both read and write. > > This works OK for normal use, but may result in all kinds of interesting > false positives/false negatives when UML is used to run unit tests > against a change which changes interrupt behavior. > > IMO it may be useful to consider some alternatives specifically for unit > test coverage purposes where printk and/or the whole console output > altogether bypass some of the IRQ driven semantics. Whoops, sorry, didn't see your comment before I went on vacation. I completely agree. It is also annoying when trying to test other really low level parts of the kernel. I would really like to get KUnit to the point where it does not have any dependencies on anything in the kernel, but that is very challenging for many reasons. This loosely relates to what Luis, myself, and others have talked about in other threads about having a stricter notion of code dependencies in the kernel. Thinking about it now, I suspect it might be easier to limit KUnit's dependency on kernel infrastructure first; that could kind of motivate the later work. From mboxrd@z Thu Jan 1 00:00:00 1970 From: brendanhiggins at google.com (Brendan Higgins) Date: Fri, 8 Feb 2019 16:40:08 -0800 Subject: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel In-Reply-To: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> <20181206153718.GD24603@bombadil.infradead.org> <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> <20181211094140.2a928fe7@gandalf.local.home> <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> Message-ID: On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov wrote: > > > On 12/11/18 2:41 PM, Steven Rostedt wrote: > > On Tue, 11 Dec 2018 15:09:26 +0100 > > Petr Mladek wrote: > > > >>> We have liburcu already, which is good. The main sticking points are: > >>> > >>> - printk has started adding a lot of %pX enhancements which printf > >>> obviously doesn't know about. > >> I wonder how big problem it is and if it is worth using another > >> approach. > > No, please do not change the %pX approach. > > > >> An alternative would be to replace them with helper functions > >> the would produce the same string. The meaning would be easier > >> to understand. But concatenating with the surrounding text > >> would be less elegant. People might start using pr_cont() > >> that is problematic (mixed lines). > >> > >> Also the %pX formats are mostly used to print context of some > >> structures. Even the helper functions would need some maintenance > >> to keep them compatible. > >> > >> BTW: The printk() feature has been introduced 10 years ago by > >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure > >> support for extended '%p' specifiers"). > > trace-cmd and perf know about most of the %pX data and how to read it. > > Perhaps we can extend the libtraceevent library to export a generic way > > to read data from printk() output for other tools to use. > > Going back for a second to using UML for this. UML console at present is > interrupt driven - it emulates serial IO using several different > back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on > the host side are used to trigger the UML interrupts - both read and write. > > This works OK for normal use, but may result in all kinds of interesting > false positives/false negatives when UML is used to run unit tests > against a change which changes interrupt behavior. > > IMO it may be useful to consider some alternatives specifically for unit > test coverage purposes where printk and/or the whole console output > altogether bypass some of the IRQ driven semantics. Whoops, sorry, didn't see your comment before I went on vacation. I completely agree. It is also annoying when trying to test other really low level parts of the kernel. I would really like to get KUnit to the point where it does not have any dependencies on anything in the kernel, but that is very challenging for many reasons. This loosely relates to what Luis, myself, and others have talked about in other threads about having a stricter notion of code dependencies in the kernel. Thinking about it now, I suspect it might be easier to limit KUnit's dependency on kernel infrastructure first; that could kind of motivate the later work. From mboxrd@z Thu Jan 1 00:00:00 1970 From: brendanhiggins@google.com (Brendan Higgins) Date: Fri, 8 Feb 2019 16:40:08 -0800 Subject: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel In-Reply-To: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> <20181206153718.GD24603@bombadil.infradead.org> <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> <20181211094140.2a928fe7@gandalf.local.home> <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> Message-ID: Content-Type: text/plain; charset="UTF-8" Message-ID: <20190209004008.s_HPBckATWCgqbNUnAOEXSqyoc2nsaHnMdOlo5_8MrE@z> On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov wrote: > > > On 12/11/18 2:41 PM, Steven Rostedt wrote: > > On Tue, 11 Dec 2018 15:09:26 +0100 > > Petr Mladek wrote: > > > >>> We have liburcu already, which is good. The main sticking points are: > >>> > >>> - printk has started adding a lot of %pX enhancements which printf > >>> obviously doesn't know about. > >> I wonder how big problem it is and if it is worth using another > >> approach. > > No, please do not change the %pX approach. > > > >> An alternative would be to replace them with helper functions > >> the would produce the same string. The meaning would be easier > >> to understand. But concatenating with the surrounding text > >> would be less elegant. People might start using pr_cont() > >> that is problematic (mixed lines). > >> > >> Also the %pX formats are mostly used to print context of some > >> structures. Even the helper functions would need some maintenance > >> to keep them compatible. > >> > >> BTW: The printk() feature has been introduced 10 years ago by > >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure > >> support for extended '%p' specifiers"). > > trace-cmd and perf know about most of the %pX data and how to read it. > > Perhaps we can extend the libtraceevent library to export a generic way > > to read data from printk() output for other tools to use. > > Going back for a second to using UML for this. UML console at present is > interrupt driven - it emulates serial IO using several different > back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on > the host side are used to trigger the UML interrupts - both read and write. > > This works OK for normal use, but may result in all kinds of interesting > false positives/false negatives when UML is used to run unit tests > against a change which changes interrupt behavior. > > IMO it may be useful to consider some alternatives specifically for unit > test coverage purposes where printk and/or the whole console output > altogether bypass some of the IRQ driven semantics. Whoops, sorry, didn't see your comment before I went on vacation. I completely agree. It is also annoying when trying to test other really low level parts of the kernel. I would really like to get KUnit to the point where it does not have any dependencies on anything in the kernel, but that is very challenging for many reasons. This loosely relates to what Luis, myself, and others have talked about in other threads about having a stricter notion of code dependencies in the kernel. Thinking about it now, I suspect it might be easier to limit KUnit's dependency on kernel infrastructure first; that could kind of motivate the later work. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brendan Higgins Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel Date: Fri, 8 Feb 2019 16:40:08 -0800 Message-ID: References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> <20181206153718.GD24603@bombadil.infradead.org> <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> <20181211094140.2a928fe7@gandalf.local.home> <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> Sender: linux-kernel-owner@vger.kernel.org To: Anton Ivanov Cc: Steven Rostedt , Petr Mladek , brakmo@fb.com, Knut Omang , jeffm@suse.com, dri-devel@lists.freedesktop.org, Sasha Levin , Linux Trace Devel , linux-kselftest@vger.kernel.org, shuah@kernel.org, Rob Herring , Frank Rowand , linux-nvdimm@lists.01.org, mpe@ellerman.id.au, Eric Sandeen , Kieran Bingham , Matthew Wilcox , Felix Guo , Joel Stanley , Kent Overstreet , jdike@addtoit.com, Tim.Bird@sony.com, linux-um@lists.infradead.orgJulia Lawall List-Id: dri-devel@lists.freedesktop.org On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov wrote: > > > On 12/11/18 2:41 PM, Steven Rostedt wrote: > > On Tue, 11 Dec 2018 15:09:26 +0100 > > Petr Mladek wrote: > > > >>> We have liburcu already, which is good. The main sticking points are: > >>> > >>> - printk has started adding a lot of %pX enhancements which printf > >>> obviously doesn't know about. > >> I wonder how big problem it is and if it is worth using another > >> approach. > > No, please do not change the %pX approach. > > > >> An alternative would be to replace them with helper functions > >> the would produce the same string. The meaning would be easier > >> to understand. But concatenating with the surrounding text > >> would be less elegant. People might start using pr_cont() > >> that is problematic (mixed lines). > >> > >> Also the %pX formats are mostly used to print context of some > >> structures. Even the helper functions would need some maintenance > >> to keep them compatible. > >> > >> BTW: The printk() feature has been introduced 10 years ago by > >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure > >> support for extended '%p' specifiers"). > > trace-cmd and perf know about most of the %pX data and how to read it. > > Perhaps we can extend the libtraceevent library to export a generic way > > to read data from printk() output for other tools to use. > > Going back for a second to using UML for this. UML console at present is > interrupt driven - it emulates serial IO using several different > back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on > the host side are used to trigger the UML interrupts - both read and write. > > This works OK for normal use, but may result in all kinds of interesting > false positives/false negatives when UML is used to run unit tests > against a change which changes interrupt behavior. > > IMO it may be useful to consider some alternatives specifically for unit > test coverage purposes where printk and/or the whole console output > altogether bypass some of the IRQ driven semantics. Whoops, sorry, didn't see your comment before I went on vacation. I completely agree. It is also annoying when trying to test other really low level parts of the kernel. I would really like to get KUnit to the point where it does not have any dependencies on anything in the kernel, but that is very challenging for many reasons. This loosely relates to what Luis, myself, and others have talked about in other threads about having a stricter notion of code dependencies in the kernel. Thinking about it now, I suspect it might be easier to limit KUnit's dependency on kernel infrastructure first; that could kind of motivate the later work. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gsGgx-0003XS-Pk for linux-um@lists.infradead.org; Sat, 09 Feb 2019 00:40:34 +0000 Received: by mail-ot1-x341.google.com with SMTP id e24so8871258otp.11 for ; Fri, 08 Feb 2019 16:40:20 -0800 (PST) MIME-Version: 1.0 References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> <20181206153718.GD24603@bombadil.infradead.org> <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> <20181211094140.2a928fe7@gandalf.local.home> <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> In-Reply-To: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com> From: Brendan Higgins Date: Fri, 8 Feb 2019 16:40:08 -0800 Message-ID: Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Anton Ivanov Cc: brakmo@fb.com, Knut Omang , jeffm@suse.com, dri-devel@lists.freedesktop.org, Sasha Levin , Linux Trace Devel , linux-kselftest@vger.kernel.org, Frank Rowand , Rob Herring , linux-nvdimm@lists.01.org, mpe@ellerman.id.au, Eric Sandeen , Kieran Bingham , Matthew Wilcox , Felix Guo , Joel Stanley , jdike@addtoit.com, Petr Mladek , shuah@kernel.org, Tim.Bird@sony.com, Kees Cook , linux-um@lists.infradead.org, Steven Rostedt , Julia Lawall , dan.j.williams@intel.com, kunit-dev@googlegroups.com, Greg KH , Linux Kernel Mailing List , Kent Overstreet , Luis Chamberlain , Eryu Guan , Daniel Vetter , richard@nod.at, joe@perches.com, linux-fsdevel@vger.kernel.org, khilman@baylibre.com On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov wrote: > > > On 12/11/18 2:41 PM, Steven Rostedt wrote: > > On Tue, 11 Dec 2018 15:09:26 +0100 > > Petr Mladek wrote: > > > >>> We have liburcu already, which is good. The main sticking points are: > >>> > >>> - printk has started adding a lot of %pX enhancements which printf > >>> obviously doesn't know about. > >> I wonder how big problem it is and if it is worth using another > >> approach. > > No, please do not change the %pX approach. > > > >> An alternative would be to replace them with helper functions > >> the would produce the same string. The meaning would be easier > >> to understand. But concatenating with the surrounding text > >> would be less elegant. People might start using pr_cont() > >> that is problematic (mixed lines). > >> > >> Also the %pX formats are mostly used to print context of some > >> structures. Even the helper functions would need some maintenance > >> to keep them compatible. > >> > >> BTW: The printk() feature has been introduced 10 years ago by > >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure > >> support for extended '%p' specifiers"). > > trace-cmd and perf know about most of the %pX data and how to read it. > > Perhaps we can extend the libtraceevent library to export a generic way > > to read data from printk() output for other tools to use. > > Going back for a second to using UML for this. UML console at present is > interrupt driven - it emulates serial IO using several different > back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on > the host side are used to trigger the UML interrupts - both read and write. > > This works OK for normal use, but may result in all kinds of interesting > false positives/false negatives when UML is used to run unit tests > against a change which changes interrupt behavior. > > IMO it may be useful to consider some alternatives specifically for unit > test coverage purposes where printk and/or the whole console output > altogether bypass some of the IRQ driven semantics. Whoops, sorry, didn't see your comment before I went on vacation. I completely agree. It is also annoying when trying to test other really low level parts of the kernel. I would really like to get KUnit to the point where it does not have any dependencies on anything in the kernel, but that is very challenging for many reasons. This loosely relates to what Luis, myself, and others have talked about in other threads about having a stricter notion of code dependencies in the kernel. Thinking about it now, I suspect it might be easier to limit KUnit's dependency on kernel infrastructure first; that could kind of motivate the later work. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um