Thank you very much for the answers, it has been very useful.
El sáb., 5 oct. 2019 a las 11:00, <kernelnewbies-request@xxxxxxxxxxxxxxxxx> escribió:
Send Kernelnewbies mailing list submissions to
kernelnewbies@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxx
You can reach the person managing the list at
kernelnewbies-owner@xxxxxxxxxxxxxxxxx
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@xxxxxx>
To: Luca Ceresoli <luca@xxxxxxxxxxxxxxxx>
Cc: Greg KH <greg@xxxxxxxxx>, kernelnewbies@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx>
To: kernelnewbies@xxxxxxxxxxxxxxxxx
Subject: Test the kernel code
Message-ID:
<CABfRCzh5=ah=JKZYXFdVGzpfWsJagodVKLNm4wKrDij-ocPgyw@xxxxxxxxxxxxxx>
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@xxxxxxxxx>
To: CRISTIAN ANDRES VARGAS GONZALEZ <vargascristian@xxxxxxxxxxxxxxxx>
Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
Subject: Re: Test the kernel code
Message-ID: <20191005035212.GA4397@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxx
> 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@xxxxxx>
To: CRISTIAN ANDRES VARGAS GONZALEZ <vargascristian@xxxxxxxxxxxxxxxx>
Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
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@xxxxxxxxx>
To: kernelnewbies@xxxxxxxxxxxxxxxxx
Subject: suspend mode
Message-ID: <d115dfae-e71c-69f3-05d1-4dc6012ae647@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
------------------------------
End of Kernelnewbies Digest, Vol 107, Issue 5
*********************************************
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
