All of lore.kernel.org
 help / color / mirror / Atom feed

diff for duplicates of <36B37F85-C952-4D2E-912C-B2BDA34430DA@mac.com>

diff --git a/a/1.txt b/N1/1.txt
index 821904c..147d9b0 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -16,40 +16,44 @@
 
 Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.
 
-We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V ?virt? machine that is currently in QEMU.
+We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V “virt” machine that is currently in QEMU.
 
 That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.
 
 > with nothing in spike *other* than the serial console, it's the only
 > way in and out.
 
-That?s likely to change.
+That’s likely to change.
 
 There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).
 
 Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.
 
-A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It?s a simple boot console.
+A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It’s a simple boot console.
 
 Apologies Luke, this is not directed at you, rather it is directed at SBI.
 
 I think we should seriously question any interface we add to SBI.
 
-- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can?t or shouldn?t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.
+- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can’t or shouldn’t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.
 
-- SBI shouldn?t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don?t yet have hardware for. It?s equally possible that we can make bad software interfaces.
+- SBI shouldn’t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don’t yet have hardware for. It’s equally possible that we can make bad software interfaces.
 
 There are some points up for discussion regards HALs.
 
 There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.
 
-We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don?t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.
+We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don’t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.
 
 I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.
 
-Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he?d like to see... possibly not an in-kernel byte-code interpreter...
+Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he’d like to see... possibly not an in-kernel byte-code interpreter...
 
 
 BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.
 
-Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.
\ No newline at end of file
+Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.
+_______________________________________________
+linux-riscv mailing list
+linux-riscv@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-riscv
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 6e2525c..0259ca4 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -20,16 +20,37 @@
   "ref\0CAPweEDwDApbFofs689xvPBjoqODCeMyaYQWpgo3CuqSjQjYTvw\@mail.gmail.com\0"
 ]
 [
-  "From\0michaeljclark\@mac.com (Michael Clark)\0"
+  "From\0Michael Clark <michaeljclark\@mac.com>\0"
 ]
 [
-  "Subject\0[sw-dev] SBI extension proposal v2\0"
+  "Subject\0Re: [sw-dev] SBI extension proposal v2\0"
 ]
 [
   "Date\0Tue, 13 Nov 2018 14:22:42 +1300\0"
 ]
 [
-  "To\0linux-riscv\@lists.infradead.org\0"
+  "To\0Luke Kenneth Casson Leighton <lkcl\@lkcl.net>\0"
+]
+[
+  "Cc\0mark.rutland\@arm.com",
+  " hch\@infradead.org",
+  " Damien.LeMoal\@wdc.com",
+  " Olof Johansson <olof.johansson\@gmail.com>",
+  " alankao\@andestech.com",
+  " abner.chang\@hpe.com",
+  " atish.patra\@wdc.com",
+  " Anup Patel <anup\@brainfault.org>",
+  " Palmer Dabbelt <palmer\@sifive.com>",
+  " Alexander Graf <agraf\@suse.de>",
+  " zong\@andestech.com",
+  " ron minnich <rminnich\@gmail.com>",
+  " mick\@ics.forth.gr",
+  " sw-dev\@groups.riscv.org",
+  " paul.walmsley\@sifive.com",
+  " Olof Johansson <olof\@lixom.net>",
+  " Alistair.Francis\@wdc.com",
+  " linux-riscv\@lists.infradead.org",
+  " Andrew Waterman <andrew\@sifive.com>\0"
 ]
 [
   "\0000:1\0"
@@ -56,43 +77,47 @@
   "\n",
   "Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.\n",
   "\n",
-  "We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V ?virt? machine that is currently in QEMU.\n",
+  "We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V \342\200\234virt\342\200\235 machine that is currently in QEMU.\n",
   "\n",
   "That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.\n",
   "\n",
   "> with nothing in spike *other* than the serial console, it's the only\n",
   "> way in and out.\n",
   "\n",
-  "That?s likely to change.\n",
+  "That\342\200\231s likely to change.\n",
   "\n",
   "There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).\n",
   "\n",
   "Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.\n",
   "\n",
-  "A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It?s a simple boot console.\n",
+  "A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It\342\200\231s a simple boot console.\n",
   "\n",
   "Apologies Luke, this is not directed at you, rather it is directed at SBI.\n",
   "\n",
   "I think we should seriously question any interface we add to SBI.\n",
   "\n",
-  "- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can?t or shouldn?t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.\n",
+  "- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can\342\200\231t or shouldn\342\200\231t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.\n",
   "\n",
-  "- SBI shouldn?t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don?t yet have hardware for. It?s equally possible that we can make bad software interfaces.\n",
+  "- SBI shouldn\342\200\231t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don\342\200\231t yet have hardware for. It\342\200\231s equally possible that we can make bad software interfaces.\n",
   "\n",
   "There are some points up for discussion regards HALs.\n",
   "\n",
   "There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.\n",
   "\n",
-  "We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don?t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.\n",
+  "We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don\342\200\231t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.\n",
   "\n",
   "I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.\n",
   "\n",
-  "Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he?d like to see... possibly not an in-kernel byte-code interpreter...\n",
+  "Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he\342\200\231d like to see... possibly not an in-kernel byte-code interpreter...\n",
   "\n",
   "\n",
   "BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.\n",
   "\n",
-  "Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change."
+  "Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.\n",
+  "_______________________________________________\n",
+  "linux-riscv mailing list\n",
+  "linux-riscv\@lists.infradead.org\n",
+  "http://lists.infradead.org/mailman/listinfo/linux-riscv"
 ]
 
-b7aea9ee57743f26a7cfc4f6f45d6bd87e624bf1fb21db41d54bb43eb86d0774
+75abec020d9795edd4e74e9c33f62ec83d083ef5248719a49b59f84460ee42cc
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.