Kernel Newbies archive on lore.kernel.org
 help / color / Atom feed
* Re: Kernelnewbies Digest, Vol 107, Issue 5
       [not found] <mailman.1.1570291202.17130.kernelnewbies@kernelnewbies.org>
@ 2019-10-07 14:41 ` CRISTIAN ANDRES VARGAS GONZALEZ
  0 siblings, 0 replies; only message in thread
From: CRISTIAN ANDRES VARGAS GONZALEZ @ 2019-10-07 14:41 UTC (permalink / raw)
  To: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 9616 bytes --]

Thank you very much for the answers, it has been very useful.

El sáb., 5 oct. 2019 a las 11:00, <kernelnewbies-request@kernelnewbies.org>
escribió:

> Send Kernelnewbies mailing list submissions to
>         kernelnewbies@kernelnewbies.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> or, via email, send a message with subject or body 'help' to
>         kernelnewbies-request@kernelnewbies.org
>
> You can reach the person managing the list at
>         kernelnewbies-owner@kernelnewbies.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kernelnewbies digest..."
>
>
> Today's Topics:
>
>    1. Re: Remote I/O bus (Valdis Kl=?utf-8?Q?=c4=93?=tnieks)
>    2. Test the kernel code (CRISTIAN ANDRES VARGAS GONZALEZ)
>    3. Re: Test the kernel code (Adam Zerella)
>    4. Re: Test the kernel code (Valdis Kl=?utf-8?Q?=c4=93?=tnieks)
>    5. suspend mode (nunojsa)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 04 Oct 2019 17:51:17 -0400
> From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu>
> To: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Greg KH <greg@kroah.com>, kernelnewbies@kernelnewbies.org
> Subject: Re: Remote I/O bus
> Message-ID: <154634.1570225877@turing-police>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri, 04 Oct 2019 17:08:30 +0200, Luca Ceresoli said:
> > Yes, the read/write helpers are nicely isolated. However this sits in a
> > vendor kernel that tends to change a lot from one release to another, so
>
> I admit having a hard time wrapping my head around "vendor kernel that
> changes a lot from one release to another", unless you mean something like
> the RedHat Enterprise releases that updates every 2 years, and at that
> point you get hit
> with a jump of 8 or 10 kernel releases.
>
> And of course, the right answer is to fix up the driver and upstream it,
> so that
> in 2022 when your vendor does a new release, the updated driver will
> already be
> there waiting for you.
>
> And don't worry about having to do patches to update the driver to a new
> kernel
> release because APIs change - that's only a problem for out-of-tree
> drivers.  If it's
> in-tree, the person making the API change is supposed to fix your driver
> for you.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 832 bytes
> Desc: not available
> URL: <
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191004/725ce698/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 4 Oct 2019 22:07:21 -0500
> From: CRISTIAN ANDRES VARGAS GONZALEZ
>         <vargascristian@americana.edu.co>
> To: kernelnewbies@kernelnewbies.org
> Subject: Test the kernel code
> Message-ID:
>         <CABfRCzh5=ah=
> JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello
>
> I am starting to develop the kernel and I have been compiling the kernel,
> now it has been compiling for some time now. When a patch is added, should
> everything be compiled again? Or is there a different way to test the code
> that has been written?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191004/ff1bbcac/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 5 Oct 2019 13:52:12 +1000
> From: Adam Zerella <adam.zerella@gmail.com>
> To: CRISTIAN ANDRES VARGAS GONZALEZ <vargascristian@americana.edu.co>
> Cc: kernelnewbies@kernelnewbies.org
> Subject: Re: Test the kernel code
> Message-ID: <20191005035212.GA4397@gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Oct 04, 2019 at 10:07:21PM -0500, CRISTIAN ANDRES VARGAS GONZALEZ
> wrote:
> > Hello
> >
> > I am starting to develop the kernel and I have been compiling the kernel,
> > now it has been compiling for some time now. When a patch is added,
> should
> > everything be compiled again? Or is there a different way to test the
> code
> > that has been written?
>
> >From what I understand you'll only have to build the _entire_ kernel
> once and subsequent builds should be faster. The build process should
> rebuild modules that have a detected change in them.
>
> You may be able to build the kernel a bit faster by running the process
> in parallel. make has an argument of `-j` where you can specify the number
> of CPU cores to utilise, for example `make -j4` would build with 4 CPUs
> in parallel.
>
> To build an individual kernel module you can specify something like `make
> M=drivers/staging/android/`.
>
> Checkout (no pun intended) https://kernelnewbies.org/KernelBuild for more
> info.
>
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 05 Oct 2019 00:18:03 -0400
> From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu>
> To: CRISTIAN ANDRES VARGAS GONZALEZ <vargascristian@americana.edu.co>
> Cc: kernelnewbies@kernelnewbies.org
> Subject: Re: Test the kernel code
> Message-ID: <171225.1570249083@turing-police>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, 04 Oct 2019 22:07:21 -0500, CRISTIAN ANDRES VARGAS GONZALEZ said:
>
> > I am starting to develop the kernel and I have been compiling the kernel,
> > now it has been compiling for some time now. When a patch is added,
> should
> > everything be compiled again? Or is there a different way to test the
> code
> > that has been written?
>
> The kernel build is driven by 'make', which is a dependency-driven program
> that
> only rebuilds things which have changed dependencies.  How much actually
> gets
> rebuilt depends on what exactly the patch changes.
>
> It changes one .c file, it probably won't rebuild anything else.  If the
> patch
> touches a major .h file that's included in a lot of things, both direct
> *and*
> indirectly from other .h files, you will probably be looking at a long
> rebuild
> as every .c file that includes the affected .h file gets recompiled.
>
> One crucial point to keep in mind - make is *not* smart enough to
> understand
> that foo.c references 3 structures defined in bar.h - and that the patch
> touches some other structure in bar.h that isn't used in foo.c.  All it
> knows
> is that foo.c #includes bar.h, and bar.h was modified (via checking the
> timestamps), and thus a rebuild of foo.o is probably called for. If any of
> the
> dependencies (usually the included .h files, but other dependencies can be
> specified in the Makefile) has a newer last-modified timestamp than foo.c,
> foo.c is getting rebuilt.
>
> And then there's some changes that will end up forcing a rebuild of pretty
> much
> everything in sight (for instance, anything that touches the top-level
> Makefile, or certain other similar crucial files).
>
> If you're not familiar with 'make', it's probably time you learned... :)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 832 bytes
> Desc: not available
> URL: <
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191005/8fb53339/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Sat, 5 Oct 2019 12:54:14 +0200
> From: nunojsa <noname.nuno@gmail.com>
> To: kernelnewbies@kernelnewbies.org
> Subject: suspend mode
> Message-ID: <d115dfae-e71c-69f3-05d1-4dc6012ae647@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi all,
>
> I have a HWMON driver which is using simple pm options. So, I have a
> suspend() and resume() where I try
> to lock a mutex before suspending/resuming. This mutex is shared with the
> read/write path of the
> hwmon attributes. I also have a flag which is set when suspend() is done
> so that, if someone tries to
> read some attribute, will get an error since doing a read/write on the
> device bus will wake it up. Im
> starting to think that this does not make any sense. Is there any way that
> a userland process runs during
> suspend? As I understand, all tasks should be frozen before starting to
> suspend the HW devices. Is this right?
> Furthermore, now that I think about this, trying to lock the mutex on the
> PM callbacks seems dangerous
> since it can lead to deadlock (if some frozen task is helding the lock?).
> However, I definitely saw drivers
> trying to lock shared mutexes in the PM callbacks. Aren't these callbacks
> atomic? Is there any scenario where
> it makes to sense to care about concurrency in these functions?
>
>
> Thanks for the help!
> - Nuno S?
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> ------------------------------
>
> End of Kernelnewbies Digest, Vol 107, Issue 5
> *********************************************
>

[-- Attachment #1.2: Type: text/html, Size: 13144 bytes --]

<div dir="ltr"><br class="gmail-Apple-interchange-newline"><span style="font-family:arial,sans-serif;white-space:pre-wrap;background-color:rgb(248,249,250)">Thank you very much for the answers, it has been very useful.</span>  <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El sáb., 5 oct. 2019 a las 11:00, &lt;<a href="mailto:kernelnewbies-request@kernelnewbies.org">kernelnewbies-request@kernelnewbies.org</a>&gt; escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send Kernelnewbies mailing list submissions to<br>
        <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
        <a href="mailto:kernelnewbies-request@kernelnewbies.org" target="_blank">kernelnewbies-request@kernelnewbies.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:kernelnewbies-owner@kernelnewbies.org" target="_blank">kernelnewbies-owner@kernelnewbies.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of Kernelnewbies digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
   1. Re: Remote I/O bus (Valdis Kl=?utf-8?Q?=c4=93?=tnieks)<br>
   2. Test the kernel code (CRISTIAN ANDRES VARGAS GONZALEZ)<br>
   3. Re: Test the kernel code (Adam Zerella)<br>
   4. Re: Test the kernel code (Valdis Kl=?utf-8?Q?=c4=93?=tnieks)<br>
   5. suspend mode (nunojsa)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 04 Oct 2019 17:51:17 -0400<br>
From: &quot;Valdis Kl=?utf-8?Q?=c4=93?=tnieks&quot; &lt;<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>&gt;<br>
To: Luca Ceresoli &lt;<a href="mailto:luca@lucaceresoli.net" target="_blank">luca@lucaceresoli.net</a>&gt;<br>
Cc: Greg KH &lt;<a href="mailto:greg@kroah.com" target="_blank">greg@kroah.com</a>&gt;, <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Re: Remote I/O bus<br>
Message-ID: &lt;154634.1570225877@turing-police&gt;<br>
Content-Type: text/plain; charset=&quot;us-ascii&quot;<br>
<br>
On Fri, 04 Oct 2019 17:08:30 +0200, Luca Ceresoli said:<br>
&gt; Yes, the read/write helpers are nicely isolated. However this sits in a<br>
&gt; vendor kernel that tends to change a lot from one release to another, so<br>
<br>
I admit having a hard time wrapping my head around &quot;vendor kernel that<br>
changes a lot from one release to another&quot;, unless you mean something like<br>
the RedHat Enterprise releases that updates every 2 years, and at that point you get hit<br>
with a jump of 8 or 10 kernel releases.<br>
<br>
And of course, the right answer is to fix up the driver and upstream it, so that<br>
in 2022 when your vendor does a new release, the updated driver will already be<br>
there waiting for you.<br>
<br>
And don&#39;t worry about having to do patches to update the driver to a new kernel<br>
release because APIs change - that&#39;s only a problem for out-of-tree drivers.  If it&#39;s<br>
in-tree, the person making the API change is supposed to fix your driver for you.<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 832 bytes<br>
Desc: not available<br>
URL: &lt;<a href="http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191004/725ce698/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191004/725ce698/attachment-0001.sig</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 4 Oct 2019 22:07:21 -0500<br>
From: CRISTIAN ANDRES VARGAS GONZALEZ<br>
        &lt;<a href="mailto:vargascristian@americana.edu.co" target="_blank">vargascristian@americana.edu.co</a>&gt;<br>
To: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Test the kernel code<br>
Message-ID:<br>
        &lt;CABfRCzh5=ah=<a href="mailto:JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com" target="_blank">JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
Hello<br>
<br>
I am starting to develop the kernel and I have been compiling the kernel,<br>
now it has been compiling for some time now. When a patch is added, should<br>
everything be compiled again? Or is there a different way to test the code<br>
that has been written?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191004/ff1bbcac/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191004/ff1bbcac/attachment-0001.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 5 Oct 2019 13:52:12 +1000<br>
From: Adam Zerella &lt;<a href="mailto:adam.zerella@gmail.com" target="_blank">adam.zerella@gmail.com</a>&gt;<br>
To: CRISTIAN ANDRES VARGAS GONZALEZ &lt;<a href="mailto:vargascristian@americana.edu.co" target="_blank">vargascristian@americana.edu.co</a>&gt;<br>
Cc: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Re: Test the kernel code<br>
Message-ID: &lt;<a href="mailto:20191005035212.GA4397@gmail.com" target="_blank">20191005035212.GA4397@gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Fri, Oct 04, 2019 at 10:07:21PM -0500, CRISTIAN ANDRES VARGAS GONZALEZ wrote:<br>
&gt; Hello<br>
&gt; <br>
&gt; I am starting to develop the kernel and I have been compiling the kernel,<br>
&gt; now it has been compiling for some time now. When a patch is added, should<br>
&gt; everything be compiled again? Or is there a different way to test the code<br>
&gt; that has been written?<br>
<br>
&gt;From what I understand you&#39;ll only have to build the _entire_ kernel<br>
once and subsequent builds should be faster. The build process should<br>
rebuild modules that have a detected change in them.<br>
<br>
You may be able to build the kernel a bit faster by running the process<br>
in parallel. make has an argument of `-j` where you can specify the number<br>
of CPU cores to utilise, for example `make -j4` would build with 4 CPUs<br>
in parallel.<br>
<br>
To build an individual kernel module you can specify something like `make<br>
M=drivers/staging/android/`.<br>
<br>
Checkout (no pun intended) <a href="https://kernelnewbies.org/KernelBuild" rel="noreferrer" target="_blank">https://kernelnewbies.org/KernelBuild</a> for more info.<br>
<br>
&gt; _______________________________________________<br>
&gt; Kernelnewbies mailing list<br>
&gt; <a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
&gt; <a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sat, 05 Oct 2019 00:18:03 -0400<br>
From: &quot;Valdis Kl=?utf-8?Q?=c4=93?=tnieks&quot; &lt;<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>&gt;<br>
To: CRISTIAN ANDRES VARGAS GONZALEZ &lt;<a href="mailto:vargascristian@americana.edu.co" target="_blank">vargascristian@americana.edu.co</a>&gt;<br>
Cc: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Re: Test the kernel code<br>
Message-ID: &lt;171225.1570249083@turing-police&gt;<br>
Content-Type: text/plain; charset=&quot;utf-8&quot;<br>
<br>
On Fri, 04 Oct 2019 22:07:21 -0500, CRISTIAN ANDRES VARGAS GONZALEZ said:<br>
<br>
&gt; I am starting to develop the kernel and I have been compiling the kernel,<br>
&gt; now it has been compiling for some time now. When a patch is added, should<br>
&gt; everything be compiled again? Or is there a different way to test the code<br>
&gt; that has been written?<br>
<br>
The kernel build is driven by &#39;make&#39;, which is a dependency-driven program that<br>
only rebuilds things which have changed dependencies.  How much actually gets<br>
rebuilt depends on what exactly the patch changes.<br>
<br>
It changes one .c file, it probably won&#39;t rebuild anything else.  If the patch<br>
touches a major .h file that&#39;s included in a lot of things, both direct *and*<br>
indirectly from other .h files, you will probably be looking at a long rebuild<br>
as every .c file that includes the affected .h file gets recompiled.<br>
<br>
One crucial point to keep in mind - make is *not* smart enough to understand<br>
that foo.c references 3 structures defined in bar.h - and that the patch<br>
touches some other structure in bar.h that isn&#39;t used in foo.c.  All it knows<br>
is that foo.c #includes bar.h, and bar.h was modified (via checking the<br>
timestamps), and thus a rebuild of foo.o is probably called for. If any of the<br>
dependencies (usually the included .h files, but other dependencies can be<br>
specified in the Makefile) has a newer last-modified timestamp than foo.c,<br>
foo.c is getting rebuilt.<br>
<br>
And then there&#39;s some changes that will end up forcing a rebuild of pretty much<br>
everything in sight (for instance, anything that touches the top-level<br>
Makefile, or certain other similar crucial files).<br>
<br>
If you&#39;re not familiar with &#39;make&#39;, it&#39;s probably time you learned... :)<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 832 bytes<br>
Desc: not available<br>
URL: &lt;<a href="http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191005/8fb53339/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20191005/8fb53339/attachment-0001.sig</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Sat, 5 Oct 2019 12:54:14 +0200<br>
From: nunojsa &lt;<a href="mailto:noname.nuno@gmail.com" target="_blank">noname.nuno@gmail.com</a>&gt;<br>
To: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: suspend mode<br>
Message-ID: &lt;<a href="mailto:d115dfae-e71c-69f3-05d1-4dc6012ae647@gmail.com" target="_blank">d115dfae-e71c-69f3-05d1-4dc6012ae647@gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi all,<br>
<br>
I have a HWMON driver which is using simple pm options. So, I have a suspend() and resume() where I try<br>
to lock a mutex before suspending/resuming. This mutex is shared with the read/write path of the<br>
hwmon attributes. I also have a flag which is set when suspend() is done so that, if someone tries to<br>
read some attribute, will get an error since doing a read/write on the device bus will wake it up. Im<br>
starting to think that this does not make any sense. Is there any way that a userland process runs during<br>
suspend? As I understand, all tasks should be frozen before starting to suspend the HW devices. Is this right?<br>
Furthermore, now that I think about this, trying to lock the mutex on the PM callbacks seems dangerous<br>
since it can lead to deadlock (if some frozen task is helding the lock?). However, I definitely saw drivers<br>
trying to lock shared mutexes in the PM callbacks. Aren&#39;t these callbacks atomic? Is there any scenario where<br>
it makes to sense to care about concurrency in these functions?<br>
<br>
<br>
Thanks for the help!<br>
- Nuno S?<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Kernelnewbies Digest, Vol 107, Issue 5<br>
*********************************************<br>
</blockquote></div>

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, back to index

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.1.1570291202.17130.kernelnewbies@kernelnewbies.org>
2019-10-07 14:41 ` Kernelnewbies Digest, Vol 107, Issue 5 CRISTIAN ANDRES VARGAS GONZALEZ

Kernel Newbies archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org
	public-inbox-index kernelnewbies

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git