<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, <<a href="mailto:kernelnewbies-request@kernelnewbies.org">kernelnewbies-request@kernelnewbies.org</a>> 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 'help' 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 "Re: Contents of Kernelnewbies digest..."<br>
<br>
<br>
Today'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: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>><br>
To: Luca Ceresoli <<a href="mailto:luca@lucaceresoli.net" target="_blank">luca@lucaceresoli.net</a>><br>
Cc: Greg KH <<a href="mailto:greg@kroah.com" target="_blank">greg@kroah.com</a>>, <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Re: Remote I/O bus<br>
Message-ID: <154634.1570225877@turing-police><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Fri, 04 Oct 2019 17:08:30 +0200, Luca Ceresoli said:<br>
> Yes, the read/write helpers are nicely isolated. However this sits in a<br>
> 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 "vendor kernel that<br>
changes a lot from one release to another", 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't worry about having to do patches to update the driver to a new kernel<br>
release because APIs change - that's only a problem for out-of-tree drivers. If it'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: <<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>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 4 Oct 2019 22:07:21 -0500<br>
From: CRISTIAN ANDRES VARGAS GONZALEZ<br>
<<a href="mailto:vargascristian@americana.edu.co" target="_blank">vargascristian@americana.edu.co</a>><br>
To: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Test the kernel code<br>
Message-ID:<br>
<CABfRCzh5=ah=<a href="mailto:JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com" target="_blank">JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<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: <<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>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 5 Oct 2019 13:52:12 +1000<br>
From: Adam Zerella <<a href="mailto:adam.zerella@gmail.com" target="_blank">adam.zerella@gmail.com</a>><br>
To: CRISTIAN ANDRES VARGAS GONZALEZ <<a href="mailto:vargascristian@americana.edu.co" target="_blank">vargascristian@americana.edu.co</a>><br>
Cc: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Re: Test the kernel code<br>
Message-ID: <<a href="mailto:20191005035212.GA4397@gmail.com" target="_blank">20191005035212.GA4397@gmail.com</a>><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>
> 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>
<br>
>From what I understand you'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>
> _______________________________________________<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>
------------------------------<br>
<br>
Message: 4<br>
Date: Sat, 05 Oct 2019 00:18:03 -0400<br>
From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>><br>
To: CRISTIAN ANDRES VARGAS GONZALEZ <<a href="mailto:vargascristian@americana.edu.co" target="_blank">vargascristian@americana.edu.co</a>><br>
Cc: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: Re: Test the kernel code<br>
Message-ID: <171225.1570249083@turing-police><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Fri, 04 Oct 2019 22:07:21 -0500, CRISTIAN ANDRES VARGAS GONZALEZ said:<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>
<br>
The kernel build is driven by 'make', 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't rebuild anything else. If the patch<br>
touches a major .h file that'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'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'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're not familiar with 'make', it'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: <<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>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Sat, 5 Oct 2019 12:54:14 +0200<br>
From: nunojsa <<a href="mailto:noname.nuno@gmail.com" target="_blank">noname.nuno@gmail.com</a>><br>
To: <a href="mailto:kernelnewbies@kernelnewbies.org" target="_blank">kernelnewbies@kernelnewbies.org</a><br>
Subject: suspend mode<br>
Message-ID: <<a href="mailto:d115dfae-e71c-69f3-05d1-4dc6012ae647@gmail.com" target="_blank">d115dfae-e71c-69f3-05d1-4dc6012ae647@gmail.com</a>><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'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>