Re: Kernelnewbies Digest, Vol 107, Issue 5

Re: Kernelnewbies Digest, Vol 107, Issue 5

[CRISTIAN ANDRES VARGAS GONZALEZ]

[-- 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 --]

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

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