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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 CA244C47404 for ; Mon, 7 Oct 2019 14:43:22 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6BADD21655 for ; Mon, 7 Oct 2019 14:43:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=americana-edu-co.20150623.gappssmtp.com header.i=@americana-edu-co.20150623.gappssmtp.com header.b="p2nUrR7c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BADD21655 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=americana.edu.co Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.3) (envelope-from ) id 1iHUDi-0007py-LX; Mon, 07 Oct 2019 10:42:42 -0400 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1iHUDf-0007ps-JO for kernelnewbies@kernelnewbies.org; Mon, 07 Oct 2019 10:42:39 -0400 Received: by mail-io1-xd34.google.com with SMTP id b19so29126955iob.4 for ; Mon, 07 Oct 2019 07:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=americana-edu-co.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wC+5HAsC7yRtq6H/+a2kZWxdwPWEqndXcc7QBkCtweg=; b=p2nUrR7cz/uOfJVFku6IL2gr94utUCNuvQU7+L/u/rICuag1UoPlivRiAPNIb+JoG8 l+hEwBUtRFsxaI68Ep9y3qG8KvuqFpXkVjREVuGvc9pqKCqaKHr7k0F6t8DGQ7Kh7Koh C86bfjh6/En1tA2/j19OoayrKXGv/GjAVDOmg0iZ1aqPBToN66mXMLHkyMk8CGljD6Rx 6ZKaEbTFnebmEk5vqrsz5kiqroO0HbBe8erfwerKK0Gvl6yr/ecOQGgtPkUmeg67y6YH w0jIQAiU9VcowfLNfooHmD2mC+wUf92+SaxAMdx+fA4J77ka4Yg7LtbYgDlad5LK7DNO 7Kfw== 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; bh=wC+5HAsC7yRtq6H/+a2kZWxdwPWEqndXcc7QBkCtweg=; b=EYoUExoQkgwqdGATf1RG8kfrbb65z01QmKGlapxnsye3KtHof0LhRtd5+ZFF8c2yIO S8033GKb0nQOgspumx5I+wxPGtMe/OFOJY1TIBIPMjM0F0C2ffWLXsy/CGLOOkOIkbBy dWZjzMDP3/ZY/MKoRIsQVgdPh9niQqYuG6W6sl1CpjqVyYF5zxtWDeT23UIY/qT5DXYR U4JupqG16U3E6w0E0MvC5eX5JslHUad00rkMTupmEQaTJ0la0xuOmWDbEb8O85Qyi6Z4 zL1wv/oI7rJS5TnYa87Q2z4Yzw1KpGI+nPteot8wKO33Qrcp0qIpZfxLRvmyMnkV3eZH 9dzQ== X-Gm-Message-State: APjAAAX9hfOmQpgLJSkMQMevq10XgCyrmgtfbsL+4XrwZM2l4whHEAAi +xVfHBDpz1nGCGudExZvY/UzgKDrsiiyayqiqd++8BmCVfY= X-Google-Smtp-Source: APXvYqwPx0b5TxYZyAB3O5MJYOzdYISew837fc4lwSEpU5rRfT+yBpSbiNbpLzvt4yRtCjmPRfWmWAULlea7zGvenGw= X-Received: by 2002:a02:2e54:: with SMTP id u20mr8204595jae.5.1570459297288; Mon, 07 Oct 2019 07:41:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: CRISTIAN ANDRES VARGAS GONZALEZ Date: Mon, 7 Oct 2019 09:41:17 -0500 Message-ID: Subject: Re: Kernelnewbies Digest, Vol 107, Issue 5 To: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6794097667419365341==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============6794097667419365341== Content-Type: multipart/alternative; boundary="0000000000008ca88f0594530c4e" --0000000000008ca88f0594530c4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you very much for the answers, it has been very useful. El s=C3=A1b., 5 oct. 2019 a las 11:00, escribi=C3=B3: > 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=3D?utf-8?Q?=3Dc4=3D93?=3Dtnieks) > 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=3D?utf-8?Q?=3Dc4=3D93?=3Dtnieks= ) > 5. suspend mode (nunojsa) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 04 Oct 2019 17:51:17 -0400 > From: "Valdis Kl=3D?utf-8?Q?=3Dc4=3D93?=3Dtnieks" > To: Luca Ceresoli > Cc: Greg KH , kernelnewbies@kernelnewbies.org > Subject: Re: Remote I/O bus > Message-ID: <154634.1570225877@turing-police> > Content-Type: text/plain; charset=3D"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, s= o > > 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 lik= e > 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/201910= 04/725ce698/attachment-0001.sig > > > > ------------------------------ > > Message: 2 > Date: Fri, 4 Oct 2019 22:07:21 -0500 > From: CRISTIAN ANDRES VARGAS GONZALEZ > > To: kernelnewbies@kernelnewbies.org > Subject: Test the kernel code > Message-ID: > JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com> > Content-Type: text/plain; charset=3D"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, shoul= d > everything be compiled again? Or is there a different way to test the cod= e > that has been written? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/201910= 04/ff1bbcac/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Sat, 5 Oct 2019 13:52:12 +1000 > From: Adam Zerella > To: CRISTIAN ANDRES VARGAS GONZALEZ > Cc: kernelnewbies@kernelnewbies.org > Subject: Re: Test the kernel code > Message-ID: <20191005035212.GA4397@gmail.com> > Content-Type: text/plain; charset=3Dus-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 kerne= l, > > 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 numbe= r > 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=3Ddrivers/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=3D?utf-8?Q?=3Dc4=3D93?=3Dtnieks" > To: CRISTIAN ANDRES VARGAS GONZALEZ > Cc: kernelnewbies@kernelnewbies.org > Subject: Re: Test the kernel code > Message-ID: <171225.1570249083@turing-police> > Content-Type: text/plain; charset=3D"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 kerne= l, > > 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 progra= m > 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 o= f > the > dependencies (usually the included .h files, but other dependencies can b= e > 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 prett= y > 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/201910= 05/8fb53339/attachment-0001.sig > > > > ------------------------------ > > Message: 5 > Date: Sat, 5 Oct 2019 12:54:14 +0200 > From: nunojsa > To: kernelnewbies@kernelnewbies.org > Subject: suspend mode > Message-ID: > Content-Type: text/plain; charset=3Dutf-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 tha= t > 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 > ********************************************* > --0000000000008ca88f0594530c4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

El s=C3=A1b., 5 oct. 2019 a las 11:00, <kernelnewbies-request@k= ernelnewbies.org> escribi=C3=B3:
Send Kernelnewbies mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 kernelnewbies@kernelnewbies.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://li= sts.kernelnewbies.org/mailman/listinfo/kernelnewbies
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 kernelnewbies-request@kernelnewbies.org
You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A01. Re: Remote I/O bus (Valdis Kl=3D?utf-8?Q?=3Dc4=3D93?=3Dtnie= ks)
=C2=A0 =C2=A02. Test the kernel code (CRISTIAN ANDRES VARGAS GONZALEZ)
=C2=A0 =C2=A03. Re: Test the kernel code (Adam Zerella)
=C2=A0 =C2=A04. Re: Test the kernel code (Valdis Kl=3D?utf-8?Q?=3Dc4=3D93?= =3Dtnieks)
=C2=A0 =C2=A05. suspend mode (nunojsa)


----------------------------------------------------------------------

Message: 1
Date: Fri, 04 Oct 2019 17:51:17 -0400
From: "Valdis Kl=3D?utf-8?Q?=3Dc4=3D93?=3Dtnieks" <valdis.kletnieks@vt.edu>
To: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Greg KH <greg@kr= oah.com>, kernelnewbies@kernelnewbies.org
Subject: Re: Remote I/O bus
Message-ID: <154634.1570225877@turing-police>
Content-Type: text/plain; charset=3D"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 poin= t 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 alread= y be
there waiting for you.

And don't worry about having to do patches to update the driver to a ne= w kernel
release because APIs change - that's only a problem for out-of-tree dri= vers.=C2=A0 If it's
in-tree, the person making the API change is supposed to fix your driver fo= r 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/attachm= ents/20191004/725ce698/attachment-0001.sig>

------------------------------

Message: 2
Date: Fri, 4 Oct 2019 22:07:21 -0500
From: CRISTIAN ANDRES VARGAS GONZALEZ
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <vargascristian@americana.edu.co>
To: ke= rnelnewbies@kernelnewbies.org
Subject: Test the kernel code
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CABfRCzh5=3Dah=3DJKZYXFdVGz= pfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com>
Content-Type: text/plain; charset=3D"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<= br> everything be compiled again? Or is there a different way to test the code<= br> that has been written?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attach= ments/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: ke= rnelnewbies@kernelnewbies.org
Subject: Re: Test the kernel code
Message-ID: <20191005035212.GA4397@gmail.com>
Content-Type: text/plain; charset=3Dus-ascii

On Fri, Oct 04, 2019 at 10:07:21PM -0500, CRISTIAN ANDRES VARGAS GONZALEZ w= rote:
> Hello
>
> I am starting to develop the kernel and I have been compiling the kern= el,
> now it has been compiling for some time now. When a patch is added, sh= ould
> 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_ kerne= l
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<= br> 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=3Ddrivers/staging/android/`.

Checkout (no pun intended) https://kernelnewbies.org/KernelBuil= d for more info.

> _______________________________________________
> Kernelnewbies mailing list
> K= ernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/m= ailman/listinfo/kernelnewbies




------------------------------

Message: 4
Date: Sat, 05 Oct 2019 00:18:03 -0400
From: "Valdis Kl=3D?utf-8?Q?=3Dc4=3D93?=3Dtnieks" <valdis.kletnieks@vt.edu>
To: CRISTIAN ANDRES VARGAS GONZALEZ <vargascristian@americana.edu.co> Cc: ke= rnelnewbies@kernelnewbies.org
Subject: Re: Test the kernel code
Message-ID: <171225.1570249083@turing-police>
Content-Type: text/plain; charset=3D"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 kern= el,
> now it has been compiling for some time now. When a patch is added, sh= ould
> 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.=C2=A0 How much actual= ly gets
rebuilt depends on what exactly the patch changes.

It changes one .c file, it probably won't rebuild anything else.=C2=A0 = 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 rebu= ild
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 understan= d
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.=C2=A0 A= ll 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<= br> specified in the Makefile) has a newer last-modified timestamp than foo.c,<= br> foo.c is getting rebuilt.

And then there's some changes that will end up forcing a rebuild of pre= tty 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/attachm= ents/20191005/8fb53339/attachment-0001.sig>

------------------------------

Message: 5
Date: Sat, 5 Oct 2019 12:54:14 +0200
From: nunojsa <noname.nuno@gmail.com>
To: ke= rnelnewbies@kernelnewbies.org
Subject: suspend mode
Message-ID: <d115dfae-e71c-69f3-05d1-4dc6012ae647@gmail.com= >
Content-Type: text/plain; charset=3Dutf-8

Hi all,

I have a HWMON driver which is using simple pm options. So, I have a suspen= d() and resume() where I try
to lock a mutex before suspending/resuming. This mutex is shared with the r= ead/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 devi= ce 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 sus= pend the HW devices. Is this right?
Furthermore, now that I think about this, trying to lock the mutex on the P= M callbacks seems dangerous
since it can lead to deadlock (if some frozen task is helding the lock?). H= owever, I definitely saw drivers
trying to lock shared mutexes in the PM callbacks. Aren't these callbac= ks 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
Kernel= newbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailma= n/listinfo/kernelnewbies


------------------------------

End of Kernelnewbies Digest, Vol 107, Issue 5
*********************************************
--0000000000008ca88f0594530c4e-- --===============6794097667419365341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============6794097667419365341==--