All of lore.kernel.org
 help / color / mirror / 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 --]

[-- 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, other threads:[~2019-10-07 14:43 UTC | newest]

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.