Thank you very much for the answers, it has been very useful. El sáb., 5 oct. 2019 a las 11:00, 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" > 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="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 > > To: kernelnewbies@kernelnewbies.org > Subject: Test the kernel code > Message-ID: > 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 > 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=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" > 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="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 > To: kernelnewbies@kernelnewbies.org > Subject: suspend mode > Message-ID: > 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 > ********************************************* >