Re: How to find all PCI/ USB/ drivers installed on my Ubuntu?

2024-09-12 Thread Greg KH
On Thu, Sep 12, 2024 at 10:23:57AM +0530, S wrote:
> Like lsusb will tell me all USB devices. But now let's say I have modules
> that are loading USB drivers or high level USB drivers. How to find that
> list.

Look at the driver names provided by "lsusb -tv"

> Same question for PCI

Look at the driver names provided by 'lspci -v'

For more information like this, check out the free online, if not very
old, book, "Linux Kernel in a Nutshell".

Hope this helps,

greg k-h

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


Re: TIP

2024-09-10 Thread Valentin Vidić
On Tue, Sep 10, 2024 at 11:25:02AM +1000, Joshua Rose wrote:
> If anyone else stumbles upon the 'TIP' acronym in future, it might be
> helpful to add it to the Kernel Glossary[1]. I would appreciate hearing
> the community's thoughts on this idea.

Or edit the description to describe the current purpose of this repo?

Unnamed repository; edit this file 'description' to name the repository.

-- 
Valentin

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


Re: TIP

2024-09-09 Thread Joshua Rose
> Apparently it stands for "Thomas, Ingo, Peter" because it started out
> as a shared tree for Thomas Gleixner, Ingo Molnar and Peter Anvin.

Interesting!

If anyone else stumbles upon the 'TIP' acronym in future, it might be
helpful to add it to the Kernel Glossary[1]. I would appreciate hearing
the community's thoughts on this idea.


[1]: https://kernelnewbies.org/KernelGlossary


Josh

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


Re: TIP

2024-09-09 Thread Konstantin Ryabitsev
On Mon, Sep 09, 2024 at 06:32:36PM GMT, Constantine Shulyupin wrote:
> What does "TIP" stand for in the repository
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/?

This made me curious, so I asked around. Apparently it stands for "Thomas,
Ingo, Peter" because it started out as a shared tree for Thomas Gleixner, Ingo
Molnar and Peter Anvin.

Today, it should really be called TIPPBD, because it's also shared with Peter
Zijlstra, Boris Petkov and Dave Hansen.

-K

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


Re: TIP

2024-09-09 Thread Greg KH
On Mon, Sep 09, 2024 at 06:32:36PM +0300, Constantine Shulyupin wrote:
> What does "TIP" stand for in the repository
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/?

"Thomas" "Ingo" "Peter", the original maintainers of that tree (i.e. the
x86 maintainers tree, which has now grown to other people and other
parts of the kernel.)

thanks,

greg k-h

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


Re: Question regarding appropriate mailing list

2024-09-03 Thread Greg KH
On Tue, Sep 03, 2024 at 06:26:17PM +0200, Patryk wrote:
> Hi,
> What would be the most appropriate mailing list to ask about pmbus
> drivers and power management devices like ltc29**. I'm trying to
> bring-up some LTC devices using existing drivers and I've encountered
> some problems while reading e.g. temp1_max_alarm attribute (NACK
> returned from the target device). I've found what exact line of code
> introduced in 5.15.x kernel causes this problem but I'm not sure
> whether or not that line was added according to the pmbus
> specification expectations therefore the code is fine, but it may that
> it's the device that responds incorrectly and it's behaviour does not
> adhere to the pmbus specification.

Just run scripts/get_maintainer.pl on the files you are looking at and
it will tell you the mailing lists and people to cc: about them.

For example, if you have issues with the driver core functions in
drivers/usb/serial/visor.c, you can do:
$ ./scripts/get_maintainer.pl --file drivers/usb/serial/visor.c
Johan Hovold  (maintainer:USB SERIAL SUBSYSTEM)
Greg Kroah-Hartman  (supporter:USB 
SUBSYSTEM)
linux-...@vger.kernel.org (open list:USB SERIAL SUBSYSTEM)
linux-ker...@vger.kernel.org (open list)

Hope this helps,

greg k-h

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


Re: How to contribute to the linux kernel

2024-09-02 Thread Qianqiang Liu
Hi Gustavo,

Thanks! I will take a look at it.

On Mon, Sep 02, 2024 at 08:11:57PM -0600, Gustavo A. R. Silva wrote:
> Hi!
> 
> > One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and
> > I started wondering if maybe I could contribute to the Linux kernel.
> 
> 
> If you are interested in security, fixing Coverity issues is a great way to
> contribute to the kernel. Here are some presentations that you might find
> useful:
> 
> https://embeddedor.com/slides/2017/kr/kr2017.pdf
> https://embeddedor.com/slides/2018/kr/kr2018.pdf
> https://embeddedor.com/slides/2019/kr/kr2019.pdf
> 
> You can also watch these presentations on YouTube for additional context.
> 
> You can sign up here for linux-next scans:
> https://scan.coverity.com/projects/linux-next-weekly-scan
> 
> and here for -rc scans:
> https://scan.coverity.com/projects/linux
> 
> I hope this helps.
> --
> Gustavo
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Best,
Qianqiang Liu


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


Re: How to contribute to the linux kernel

2024-09-02 Thread Gustavo A. R. Silva

Hi!

One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and I started wondering if maybe I could contribute to the Linux kernel. 



If you are interested in security, fixing Coverity issues is a great way to
contribute to the kernel. Here are some presentations that you might find
useful:

https://embeddedor.com/slides/2017/kr/kr2017.pdf
https://embeddedor.com/slides/2018/kr/kr2018.pdf
https://embeddedor.com/slides/2019/kr/kr2019.pdf

You can also watch these presentations on YouTube for additional context.

You can sign up here for linux-next scans:
https://scan.coverity.com/projects/linux-next-weekly-scan

and here for -rc scans:
https://scan.coverity.com/projects/linux

I hope this helps.
--
Gustavo

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


Re: How to contribute to the linux kernel

2024-09-02 Thread Qianqiang Liu
Hi Philipp,

Thanks, I will prepare a patch for it.

Best,
Qianqiang Liu

On Mon, Sep 02, 2024 at 07:49:25PM +0200, Philipp Hortmann wrote:
> On 8/31/24 10:17, Qianqiang Liu wrote:
> > 
> > Hi all,
> > 
> > I am an embedded software engineer. I use Linux every day, and I
> > appreciate its neatness and simplicity.
> 
> Hi Qiangiang,
> 
> it seems that the driver rtl7823bs has the following
> 
> enum p2p_wpsinfo
> structgetcountjudge_rsp
> 
> that is not used.
> 
> It makes sense to remove it.
> 
> Thanks for your support.
> 
> Bye Philipp
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


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


Re: How to contribute to the linux kernel

2024-09-02 Thread Philipp Hortmann

On 8/31/24 10:17, Qianqiang Liu wrote:


Hi all,

I am an embedded software engineer. I use Linux every day, and I 
appreciate its neatness and simplicity.


Hi Qiangiang,

it seems that the driver rtl7823bs has the following

enum p2p_wpsinfo
struct  getcountjudge_rsp

that is not used.

It makes sense to remove it.

Thanks for your support.

Bye Philipp

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


Re: How to contribute to the linux kernel

2024-08-31 Thread Qianqiang Liu
Hi Greg,

Thanks a lot.

Best,
Qianqiang Liu

On Sat, Aug 31, 2024 at 07:32:04PM +0200, Greg KH wrote:
> On Sat, Aug 31, 2024 at 04:17:35PM +0800, Qianqiang Liu wrote:
> > 
> > Hi all,
> > 
> > I am an embedded software engineer. I use Linux every day, and I appreciate 
> > its neatness and simplicity.
> > 
> > One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and I 
> > started wondering if maybe I could contribute to the Linux kernel. So, I 
> > sent a very simple (and maybe stupid) patch to the community:
> > 
> > > On Fri, Aug 30, 2024 at 04:54:38PM +0800, Qianqiang Liu wrote:
> > > There is no need to add parentheses around 'devcode != 0x' and
> > > 'devcode != 0x9320'
> > > 
> > > Signed-off-by: Qianqiang Liu 
> > > ---
> > > drivers/staging/fbtft/fb_ili9320.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/fbtft/fb_ili9320.c 
> > > b/drivers/staging/fbtft/fb_ili9320.c
> > > index 0be7c2d51548..409b54cc562e 100644
> > > --- a/drivers/staging/fbtft/fb_ili9320.c
> > > +++ b/drivers/staging/fbtft/fb_ili9320.c
> > > @@ -37,7 +37,7 @@ static int init_display(struct fbtft_par *par)
> > >devcode = read_devicecode(par);
> > >fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code: 0x%04X\n",
> > >  devcode);
> > > -if ((devcode != 0x) && (devcode != 0x9320))
> > > +if (devcode != 0x && devcode != 0x9320)
> > >dev_warn(par->info->device,
> > > "Unrecognized Device code: 0x%04X (expected 0x9320)\n",
> > >devcode);
> > > -- 
> > > 2.39.2
> > 
> > 
> > It turns out that the patch was rejected.
> 
> That's just because it's something that I don't think should be changed,
> not because it was "stupid" or anything like that.  It's been discussed
> many times in the past, not a big deal.
> 
> > So, my question is: how can I start contributing to the Linux kernel?
> > Maybe I could start by fixing some small bugs?
> 
> Sure, try reading this:
>   
> https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html
> 
> Good luck!
> 
> greg k-h
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


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


Re: How to contribute to the linux kernel

2024-08-31 Thread Greg KH
On Sat, Aug 31, 2024 at 04:17:35PM +0800, Qianqiang Liu wrote:
> 
> Hi all,
> 
> I am an embedded software engineer. I use Linux every day, and I appreciate 
> its neatness and simplicity.
> 
> One day, I watched a video from Greg: https://youtu.be/LLBrBBImJt4, and I 
> started wondering if maybe I could contribute to the Linux kernel. So, I sent 
> a very simple (and maybe stupid) patch to the community:
> 
> > On Fri, Aug 30, 2024 at 04:54:38PM +0800, Qianqiang Liu wrote:
> > There is no need to add parentheses around 'devcode != 0x' and
> > 'devcode != 0x9320'
> > 
> > Signed-off-by: Qianqiang Liu 
> > ---
> > drivers/staging/fbtft/fb_ili9320.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/fbtft/fb_ili9320.c 
> > b/drivers/staging/fbtft/fb_ili9320.c
> > index 0be7c2d51548..409b54cc562e 100644
> > --- a/drivers/staging/fbtft/fb_ili9320.c
> > +++ b/drivers/staging/fbtft/fb_ili9320.c
> > @@ -37,7 +37,7 @@ static int init_display(struct fbtft_par *par)
> >devcode = read_devicecode(par);
> >fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code: 0x%04X\n",
> >  devcode);
> > -if ((devcode != 0x) && (devcode != 0x9320))
> > +if (devcode != 0x && devcode != 0x9320)
> >dev_warn(par->info->device,
> > "Unrecognized Device code: 0x%04X (expected 0x9320)\n",
> >devcode);
> > -- 
> > 2.39.2
> 
> 
> It turns out that the patch was rejected.

That's just because it's something that I don't think should be changed,
not because it was "stupid" or anything like that.  It's been discussed
many times in the past, not a big deal.

> So, my question is: how can I start contributing to the Linux kernel?
> Maybe I could start by fixing some small bugs?

Sure, try reading this:

https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html

Good luck!

greg k-h

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


Re: Query Regarding Stack-Out-of-Bounds Error

2024-08-31 Thread Muni Sekhar
On Tue, Aug 27, 2024 at 1:16 AM Valdis Klētnieks
 wrote:
>
> On Mon, 26 Aug 2024 18:04:39 +0530, Muni Sekhar said:
>
> > static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt,
> >unsigned int opcode, int rings)
> > {
> > struct cmd_info *info = NULL;
> > unsigned int ring;
> > ...
> > for_each_set_bit(ring, (unsigned long *)&rings, I915_NUM_ENGINES) {
> >
> > In the above code, a 32-bit integer pointer (rings) is being cast to a
> > 64-bit unsigned long pointer, which leads to an extra 4 bytes being
> > accessed. This raises a concern regarding a stack-out-of-bounds bug.
> >
> > My specific query is: While it is logically understandable that a
> > write operation involving these extra 4 bytes could cause a kernel
> > crash, in this case, it is a read operation that is occurring.
>
> Note that 'ring' is located in the stack frame for the current function. So to
> complete the analysis - is there any way that the stack frame can be located 
> in
> such a way that 'ring' is the *very last* 4 bytes on a page, and the next page
> *isn't* allocated, *and* I915_NUM_ENGINES is big enough to cause the loop to 
> walk
> off the end?
>
> For bonus points, part 1:  Does the answer depend on whether the architecture
> has stacks that grow up, or grow down in address?

Here’s an example stack frame for context:

|---|
| Return Address |
|---|
| Saved Frame Pointer |
|---|
| Parameter: gvt |
|---|
| Parameter: opcode |
|---|
| Parameter: rings |
|---|
| Local Variable: info |
|---|
| Local Variable: ring |
|---|

Stack Growth Downwards:
If the stack grows downward in address space, is there any scenario
where the stack frame could be positioned such that the return address
is located at the very last 4 bytes of a page, the next page isn't
allocated, and I915_NUM_ENGINES is large enough to cause the loop to
walk off the end? If this happens, would it result in a
stack-out-of-bounds error leading to a kernel crash?

Stack Growth Upwards:
Conversely, if the stack grows upward, could the stack frame be
positioned in such a way that the 'ring' variable is at the very last
4 bytes of a page, and the next page isn’t allocated, with
I915_NUM_ENGINES being large enough to cause the loop to walk off the
end? Would this also result in a stack-out-of-bounds error causing a
kernel crash?

I'm curious as to why the likelihood of this error seems to depend on
whether the architecture has stacks that grow up or down in address
space. In both scenarios stack-out-of-bounds error behaves the same,
right?

>
> For bonus points, part 2: can this function be called quickly enough, and
> enough times, that it can be abused to do something interesting to L1/L2 cache
> and speculative execution, because some systems will fetch not only the bytes
> needed, but as much as 64 or 128 bytes of cache line?  Can you name 3 security
> bugs that abused this sort of thing?
Where should I look to find more details about these security bugs?
I appreciate your insights on these questions.
>
> Free hint:  There's a bit of interesting code in kernel/exit.c that tells you 
> if
> your system has gotten close to running out of kernel stack.
>
> [/usr/src/linux-next] dmesg | grep 'greatest stack'
> [1.093400] [ T40] pgdatinit0 (40) used greatest stack depth: 13920 
> bytes left
> [3.832907] [ T82] modprobe (82) used greatest stack depth: 8 bytes 
> left
>
> Hmm... wonder how that modprobe managed *that* :)
>
>
>


-- 
Thanks,
Sekhar

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


Re: Reproducing syzbot

2024-08-30 Thread Dongliang Mu
On Sat, Aug 31, 2024 at 8:29 AM Kenneth Adam Miller
 wrote:
>
> Is there any way to obtain a downloadable version of something executable 
> from syzbot that demonstrates the errors encountered?

If I understand correctly, you can refer to syzbot_assets[1].

BTW, in my mind, this email should be sent to the syzkaller mailing
list instead of here.

[1] https://github.com/google/syzkaller/blob/master/docs/syzbot_assets.md

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

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


Re: Query Regarding Stack-Out-of-Bounds Error

2024-08-27 Thread Muni Sekhar
On Tue, Aug 27, 2024 at 1:16 AM Valdis Klētnieks
 wrote:
>
> On Mon, 26 Aug 2024 18:04:39 +0530, Muni Sekhar said:
>
> > static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt,
> >unsigned int opcode, int rings)
> > {
> > struct cmd_info *info = NULL;
> > unsigned int ring;
> > ...
> > for_each_set_bit(ring, (unsigned long *)&rings, I915_NUM_ENGINES) {
> >
> > In the above code, a 32-bit integer pointer (rings) is being cast to a
> > 64-bit unsigned long pointer, which leads to an extra 4 bytes being
> > accessed. This raises a concern regarding a stack-out-of-bounds bug.
> >
> > My specific query is: While it is logically understandable that a
> > write operation involving these extra 4 bytes could cause a kernel
> > crash, in this case, it is a read operation that is occurring.
>
> Note that 'ring' is located in the stack frame for the current function. So to
> complete the analysis - is there any way that the stack frame can be located 
> in
> such a way that 'ring' is the *very last* 4 bytes on a page, and the next page
> *isn't* allocated, *and* I915_NUM_ENGINES is big enough to cause the loop to 
> walk
> off the end?
>
> For bonus points, part 1:  Does the answer depend on whether the architecture
> has stacks that grow up, or grow down in address?

Stack Frame Example

|---|
| Return Address|
|---|
| Saved Frame Pointer   |
|---|
| Parameter: gvt|
|---|
| Parameter: opcode |
|---|
| Parameter: rings  |
|---|
| Local Variable: info  |
|---|
| Local Variable: ring  |
|---|

If the stack grows downwards, the previous 32 bits (4 bytes) before
rings will be read as part of the 64-bit value.
If the stack grows upwards, the next 32 bits (4 bytes) after rings
will be read as part of the 64-bit value.
Consider that the stack grows upwards and the "ring" variable is
located at the very end of a stack page. What should be the value of
I915_NUM_ENGINES to trigger the Stack-Out-of-Bounds crash?

>
> For bonus points, part 2: can this function be called quickly enough, and
> enough times, that it can be abused to do something interesting to L1/L2 cache
> and speculative execution, because some systems will fetch not only the bytes
> needed, but as much as 64 or 128 bytes of cache line?  Can you name 3 security
> bugs that abused this sort of thing?
>
> Free hint:  There's a bit of interesting code in kernel/exit.c that tells you 
> if
> your system has gotten close to running out of kernel stack.
>
> [/usr/src/linux-next] dmesg | grep 'greatest stack'
> [1.093400] [ T40] pgdatinit0 (40) used greatest stack depth: 13920 
> bytes left
> [3.832907] [ T82] modprobe (82) used greatest stack depth: 8 bytes 
> left
>
> Hmm... wonder how that modprobe managed *that* :)
>
>
>


-- 
Thanks,
Sekhar

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


Re: Query Regarding Stack-Out-of-Bounds Error

2024-08-26 Thread Valdis Klētnieks
On Mon, 26 Aug 2024 18:04:39 +0530, Muni Sekhar said:

> static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt,
>unsigned int opcode, int rings)
> {
> struct cmd_info *info = NULL;
> unsigned int ring;
> ...
> for_each_set_bit(ring, (unsigned long *)&rings, I915_NUM_ENGINES) {
>
> In the above code, a 32-bit integer pointer (rings) is being cast to a
> 64-bit unsigned long pointer, which leads to an extra 4 bytes being
> accessed. This raises a concern regarding a stack-out-of-bounds bug.
>
> My specific query is: While it is logically understandable that a
> write operation involving these extra 4 bytes could cause a kernel
> crash, in this case, it is a read operation that is occurring.

Note that 'ring' is located in the stack frame for the current function. So to
complete the analysis - is there any way that the stack frame can be located in
such a way that 'ring' is the *very last* 4 bytes on a page, and the next page
*isn't* allocated, *and* I915_NUM_ENGINES is big enough to cause the loop to 
walk
off the end?

For bonus points, part 1:  Does the answer depend on whether the architecture
has stacks that grow up, or grow down in address?

For bonus points, part 2: can this function be called quickly enough, and
enough times, that it can be abused to do something interesting to L1/L2 cache
and speculative execution, because some systems will fetch not only the bytes
needed, but as much as 64 or 128 bytes of cache line?  Can you name 3 security
bugs that abused this sort of thing?

Free hint:  There's a bit of interesting code in kernel/exit.c that tells you if
your system has gotten close to running out of kernel stack.

[/usr/src/linux-next] dmesg | grep 'greatest stack'
[1.093400] [ T40] pgdatinit0 (40) used greatest stack depth: 13920 
bytes left
[3.832907] [ T82] modprobe (82) used greatest stack depth: 8 bytes left

Hmm... wonder how that modprobe managed *that* :)




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


Re: Separating driver and documentation changes

2024-08-22 Thread Greg KH
On Thu, Aug 22, 2024 at 10:29:32AM +0200, Patryk Biel wrote:
> Hi
> I'm going to send a patch that extends existing driver with support for a new
> variant of the existing device. The changes in the drivr code are rather
> small, around 100 lines of code. Apart from the driver changes I
> would like to also update Documentation/devicetree/bindings for this
> driver to add the information about the new supported variant. Should I
> split the changes and send them separately? If so, how can I make sure
> that the documentation changes won't be merged to kernel source tree
> until the drive's modifications are merged? (if ofc maintainer decides
> to integrate them).

Make it a patch series, first patch does the bindings change and the
second does the driver change.  You will find thousands of examples of
people doing this on the development mailing lists, it's the preferred
way.

good luck!

greg k-h

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


Re: Request for information on using NVMe under linux

2024-07-03 Thread Rémi ESSAISSI

hoping not to spam:

fwupd can't flash drives ? it could be safer for you .

( https://github.com/fwupd/fwupd )



Le 03/07/2024 à 12:24, Jeffrey Walton a écrit :

On Wed, Jul 3, 2024 at 4:21 AM Jamaleddine AMGHAR  wrote:


I am experiencing an abnormal performance issue with my Samsung SSD 970 EVO 
Plus 1TB (2B2QEXM7) on my Ubuntu 24.04 LTS system. My setup includes a 12th Gen 
Intel Core i7-12700 x 20 processor, and the SSD is connected to an M.2 M-key, 
type-2280 slot (PCIe Gen.3 x4 interface) that supports NVMe on the motherboard.

Specifically, I have noticed a significantly low write speed of around 700MB/s 
on my Ubuntu system. After some research, it appears that many users face 
similar issues when using NVMe drives on Linux. In contrast, when I tested the 
same SSD on the same motherboard using a portable Windows OS, the write speed 
was approximately 3GB/s.

Could you provide any methods to optimize the performance of my NVMe drive on Linux? 
Additionally, how can I update the NVMe driver on Linux using "nvme-cli"? Any 
advice or recommendations you have to address this issue would be greatly appreciated.


To help with the second question, see
.
I used Windows on a thumb drive to update the firmware of several
Samsung SSDs used in my Linux machines.

For one of the drives, I seem to recall the program said it could not
find a Samsung SSD though it was installed. I assumed it was a
counterfeit drive from Amazon.

(I use the same WIndows thumb drive to update BIOS and UEFI, too).

Jeff

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


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


Re: Request for information on using NVMe under linux

2024-07-03 Thread Jeffrey Walton
On Wed, Jul 3, 2024 at 4:21 AM Jamaleddine AMGHAR  wrote:
>
> I am experiencing an abnormal performance issue with my Samsung SSD 970 EVO 
> Plus 1TB (2B2QEXM7) on my Ubuntu 24.04 LTS system. My setup includes a 12th 
> Gen Intel Core i7-12700 x 20 processor, and the SSD is connected to an M.2 
> M-key, type-2280 slot (PCIe Gen.3 x4 interface) that supports NVMe on the 
> motherboard.
>
> Specifically, I have noticed a significantly low write speed of around 
> 700MB/s on my Ubuntu system. After some research, it appears that many users 
> face similar issues when using NVMe drives on Linux. In contrast, when I 
> tested the same SSD on the same motherboard using a portable Windows OS, the 
> write speed was approximately 3GB/s.
>
> Could you provide any methods to optimize the performance of my NVMe drive on 
> Linux? Additionally, how can I update the NVMe driver on Linux using 
> "nvme-cli"? Any advice or recommendations you have to address this issue 
> would be greatly appreciated.

To help with the second question, see
.
I used Windows on a thumb drive to update the firmware of several
Samsung SSDs used in my Linux machines.

For one of the drives, I seem to recall the program said it could not
find a Samsung SSD though it was installed. I assumed it was a
counterfeit drive from Amazon.

(I use the same WIndows thumb drive to update BIOS and UEFI, too).

Jeff

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


Re: Request for information on using NVMe under linux

2024-07-03 Thread Richard

There are those ubuntu hwe kernels, those might help

-- Richard

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


Re: Request for information on using NVMe under linux

2024-07-03 Thread Rémi ESSAISSI

I suggest you start by

checking the kernel version, ubuntu is kinda like debian, it may be an 
"old" one (relatively) especially LTS ... .


big chances that updating your kernel will be more than sufficient .

Le 03/07/2024 à 10:20, Jamaleddine AMGHAR a écrit :

Hello,

I am experiencing an abnormal performance issue with my Samsung SSD 970 
EVO Plus 1TB (2B2QEXM7) on my Ubuntu 24.04 LTS system. My setup includes 
a 12th Gen Intel Core i7-12700 x 20 processor, and the SSD is connected 
to an M.2 M-key, type-2280 slot (PCIe Gen.3 x4 interface) that supports 
NVMe on the motherboard.


Specifically, I have noticed a significantly low write speed of around 
700MB/s on my Ubuntu system. After some research, it appears that many 
users face similar issues when using NVMe drives on Linux. In contrast, 
when I tested the same SSD on the same motherboard using a portable 
Windows OS, the write speed was approximately 3GB/s.


Could you provide any methods to optimize the performance of my NVMe 
drive on Linux? Additionally, how can I update the NVMe driver on Linux 
using "nvme-cli"? Any advice or recommendations you have to address this 
issue would be greatly appreciated.


Thank you for your assistance.

Best regards,

Jamaledd

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


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


Re: sanity check typo patch "quired"

2024-07-01 Thread daniel watson


Thanks!

"Ricardo B. Marliere"  writes:
> From a quick glance at the git blame, seems that "docs: admin-guide:
> ..." or ever "docs/admin-guide/mm" should suit better. Perhaps mention
> in the subject line that its a typo fix aswell.

I ended up going with this subject:

Subject: [PATCH] docs/admin-guide/mm: correct typo 'quired' to 'queried'

after reviewing the prior commit first lines.



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


Re: sanity check typo patch "quired"

2024-06-29 Thread Ricardo B. Marliere
On 26 Jun 24 21:30, daniel watson wrote:
> 
> here's a patch to fix a typo in the memory management docs.  i'm
> sending to this mailing list first for a sanity check.
> 
> 
> 
> From: Daniel Watson 
> To: Jonathan Corbet 
> ,linux-...@vger.kernel.org,linux-ker...@vger.kernel.org
> Date: Wed, 26 Jun 2024 21:18:22 -0700
> Subject: [PATCH] mm: docs: correct 'quired' to 'queried'

>From a quick glance at the git blame, seems that "docs: admin-guide:
..." or ever "docs/admin-guide/mm" should suit better. Perhaps mention
in the subject line that its a typo fix aswell.

> 
> Convert from the word "quired" to the word "queried" which makes more
> sense in this context.
> 
> Signed-off-by: Daniel Watson 
> ---
>  Documentation/admin-guide/mm/index.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/mm/index.rst 
> b/Documentation/admin-guide/mm/index.rst
> index 1f883abf3f00f..8b35795b664be 100644
> --- a/Documentation/admin-guide/mm/index.rst
> +++ b/Documentation/admin-guide/mm/index.rst
> @@ -10,7 +10,7 @@ processes address space and many other cool things.
>  
>  Linux memory management is a complex system with many configurable
>  settings. Most of these settings are available via ``/proc``
> -filesystem and can be quired and adjusted using ``sysctl``. These APIs
> +filesystem and can be queried and adjusted using ``sysctl``. These APIs
>  are described in Documentation/admin-guide/sysctl/vm.rst and in `man 5 
> proc`_.
>  
>  .. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html
> -- 
> 2.43.0
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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


Re: How to accout max_rss precisely

2024-06-16 Thread Heran Yang
Hi!

I do this test leverage systemd-run. The command likes:

systemd-run --user --unit test --wait ./a

Though there are some accounting bugs in systemd-run (check PR #33258), the
accounting value is aligned
with cgroups. The cgroups creating step is like this:

1. Setup a cgroup (now it has no process in it)
2. Write the pid of this process to cgroup and execve the command
immediately afterward

I guess there is no over-measuring or under-measuring during this process,
but I'm not sure.


Mulyadi Santosa  于2024年6月16日周日 21:10写道:

> Hi
>
> I think the key here is : when exactly cgroup is created for your program?
>
>
>
> On Sun, Jun 16, 2024, 15:53 Heran Yang  wrote:
>
>> Hi, and thanks for your reply. I totally forgot to take the dynamic
>> loader into consideration, which is my bad.
>>
>> But another problem is that the peak value cannot align with the max_rss
>> getting from `getrusage` function, which
>> is ~1000KiB. I guess that it has some connection with max_rss inheriting,
>> but I'm not sure about that. Do you have
>> any opinion about it?
>>
>> 杨贺然  于2024年6月4日周二 21:37写道:
>>
>>> Hi, and thanks for your reply. I totally forgot to take the dynamic
>>> loader into consideration, which is my bad.
>>>
>>> But another problem is that the peak value cannot align with the max_rss
>>> getting from `getrusage` function, which
>>> is ~1000KiB. I guess that it has some connection with max_rss
>>> inheriting, but I'm not sure about that. Do you have
>>> any opinion about it?
>>>
>>> Valdis Klētnieks  于2024年6月4日周二 01:44写道:
>>>
 On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said:

 > // a.c
 > int main() {}
 >
 > It shows that `memory.peak` of this program is ~500KiB, which does
 not make
 > sense to me.

 Makes sense to me...

 [~] cat > testnull.c
  int main() {}
 [~] gcc testnull.c
 [~] ldd a.out
 linux-vdso.so.1 (0x7efc6a65)
 libc.so.6 => /lib64/libc.so.6 (0x7efc6a43d000)
 /lib64/ld-linux-x86-64.so.2 (0x7efc6a652000)
 [~] objdump -d a.out

 a.out: file format elf64-x86-64


 Disassembly of section .init:

 00401000 <_init>:
   401000:   f3 0f 1e fa endbr64
   401004:   48 83 ec 08 sub$0x8,%rsp
   401008:   48 8b 05 d1 2f 00 00mov0x2fd1(%rip),%rax
 # 403fe0 <__gmon_start__@Base>
   40100f:   48 85 c0test   %rax,%rax
   401012:   74 02   je 401016 <_init+0x16>
   401014:   ff d0   call   *%rax
   401016:   48 83 c4 08 add$0x8,%rsp
   40101a:   c3  ret

 Disassembly of section .text:

 00401020 <_start>:
   401020:   f3 0f 1e fa endbr64
   401024:   31 ed   xor%ebp,%ebp
   401026:   49 89 d1mov%rdx,%r9
   401029:   5e  pop%rsi
   40102a:   48 89 e2mov%rsp,%rdx
   40102d:   48 83 e4 f0 and$0xfff0,%rsp
   401031:   50  push   %rax
   401032:   54  push   %rsp
   401033:   45 31 c0xor%r8d,%r8d
   401036:   31 c9   xor%ecx,%ecx
   401038:   48 c7 c7 06 11 40 00mov$0x401106,%rdi
   40103f:   ff 15 93 2f 00 00   call   *0x2f93(%rip)#
 403fd8 <__libc_start_main@GLIBC_2.34>
   401045:   f4  hlt
   401046:   66 2e 0f 1f 84 00 00cs nopw 0x0(%rax,%rax,1)
   40104d:   00 00 00
 (.)

 Basically, its not *really* a totally null program.  You've got the
 dynamic
 loader ld-linux running first, which then *doesn't* run main()
 directly, but
 rather invokes _start, which needs to happen so that __libc_start_main
 can get
 called and initialize stuff lie stdio, malloc, and other such t hings,
 before
 it finally calls main().

 Personally, I'm surprised that ld-linux and glibc initialization can
 finish
 without going over 500k - even more so if shared library text pages are
 included in memory.peak.  Somebody  else can wade into that mess, I
 admit
 having been around since kernel 2.5.47 or so, and I never did
 understand the
 memory accounting for shared text pages

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

Re: How to accout max_rss precisely

2024-06-16 Thread Mulyadi Santosa
Hi

I think the key here is : when exactly cgroup is created for your program?



On Sun, Jun 16, 2024, 15:53 Heran Yang  wrote:

> Hi, and thanks for your reply. I totally forgot to take the dynamic loader
> into consideration, which is my bad.
>
> But another problem is that the peak value cannot align with the max_rss
> getting from `getrusage` function, which
> is ~1000KiB. I guess that it has some connection with max_rss inheriting,
> but I'm not sure about that. Do you have
> any opinion about it?
>
> 杨贺然  于2024年6月4日周二 21:37写道:
>
>> Hi, and thanks for your reply. I totally forgot to take the dynamic
>> loader into consideration, which is my bad.
>>
>> But another problem is that the peak value cannot align with the max_rss
>> getting from `getrusage` function, which
>> is ~1000KiB. I guess that it has some connection with max_rss inheriting,
>> but I'm not sure about that. Do you have
>> any opinion about it?
>>
>> Valdis Klētnieks  于2024年6月4日周二 01:44写道:
>>
>>> On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said:
>>>
>>> > // a.c
>>> > int main() {}
>>> >
>>> > It shows that `memory.peak` of this program is ~500KiB, which does not
>>> make
>>> > sense to me.
>>>
>>> Makes sense to me...
>>>
>>> [~] cat > testnull.c
>>>  int main() {}
>>> [~] gcc testnull.c
>>> [~] ldd a.out
>>> linux-vdso.so.1 (0x7efc6a65)
>>> libc.so.6 => /lib64/libc.so.6 (0x7efc6a43d000)
>>> /lib64/ld-linux-x86-64.so.2 (0x7efc6a652000)
>>> [~] objdump -d a.out
>>>
>>> a.out: file format elf64-x86-64
>>>
>>>
>>> Disassembly of section .init:
>>>
>>> 00401000 <_init>:
>>>   401000:   f3 0f 1e fa endbr64
>>>   401004:   48 83 ec 08 sub$0x8,%rsp
>>>   401008:   48 8b 05 d1 2f 00 00mov0x2fd1(%rip),%rax
>>> # 403fe0 <__gmon_start__@Base>
>>>   40100f:   48 85 c0test   %rax,%rax
>>>   401012:   74 02   je 401016 <_init+0x16>
>>>   401014:   ff d0   call   *%rax
>>>   401016:   48 83 c4 08 add$0x8,%rsp
>>>   40101a:   c3  ret
>>>
>>> Disassembly of section .text:
>>>
>>> 00401020 <_start>:
>>>   401020:   f3 0f 1e fa endbr64
>>>   401024:   31 ed   xor%ebp,%ebp
>>>   401026:   49 89 d1mov%rdx,%r9
>>>   401029:   5e  pop%rsi
>>>   40102a:   48 89 e2mov%rsp,%rdx
>>>   40102d:   48 83 e4 f0 and$0xfff0,%rsp
>>>   401031:   50  push   %rax
>>>   401032:   54  push   %rsp
>>>   401033:   45 31 c0xor%r8d,%r8d
>>>   401036:   31 c9   xor%ecx,%ecx
>>>   401038:   48 c7 c7 06 11 40 00mov$0x401106,%rdi
>>>   40103f:   ff 15 93 2f 00 00   call   *0x2f93(%rip)#
>>> 403fd8 <__libc_start_main@GLIBC_2.34>
>>>   401045:   f4  hlt
>>>   401046:   66 2e 0f 1f 84 00 00cs nopw 0x0(%rax,%rax,1)
>>>   40104d:   00 00 00
>>> (.)
>>>
>>> Basically, its not *really* a totally null program.  You've got the
>>> dynamic
>>> loader ld-linux running first, which then *doesn't* run main() directly,
>>> but
>>> rather invokes _start, which needs to happen so that __libc_start_main
>>> can get
>>> called and initialize stuff lie stdio, malloc, and other such t hings,
>>> before
>>> it finally calls main().
>>>
>>> Personally, I'm surprised that ld-linux and glibc initialization can
>>> finish
>>> without going over 500k - even more so if shared library text pages are
>>> included in memory.peak.  Somebody  else can wade into that mess, I admit
>>> having been around since kernel 2.5.47 or so, and I never did understand
>>> the
>>> memory accounting for shared text pages
>>>
>>> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: How to accout max_rss precisely

2024-06-16 Thread Heran Yang
Hi, and thanks for your reply. I totally forgot to take the dynamic loader
into consideration, which is my bad.

But another problem is that the peak value cannot align with the max_rss
getting from `getrusage` function, which
is ~1000KiB. I guess that it has some connection with max_rss inheriting,
but I'm not sure about that. Do you have
any opinion about it?

杨贺然  于2024年6月4日周二 21:37写道:

> Hi, and thanks for your reply. I totally forgot to take the dynamic loader
> into consideration, which is my bad.
>
> But another problem is that the peak value cannot align with the max_rss
> getting from `getrusage` function, which
> is ~1000KiB. I guess that it has some connection with max_rss inheriting,
> but I'm not sure about that. Do you have
> any opinion about it?
>
> Valdis Klētnieks  于2024年6月4日周二 01:44写道:
>
>> On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said:
>>
>> > // a.c
>> > int main() {}
>> >
>> > It shows that `memory.peak` of this program is ~500KiB, which does not
>> make
>> > sense to me.
>>
>> Makes sense to me...
>>
>> [~] cat > testnull.c
>>  int main() {}
>> [~] gcc testnull.c
>> [~] ldd a.out
>> linux-vdso.so.1 (0x7efc6a65)
>> libc.so.6 => /lib64/libc.so.6 (0x7efc6a43d000)
>> /lib64/ld-linux-x86-64.so.2 (0x7efc6a652000)
>> [~] objdump -d a.out
>>
>> a.out: file format elf64-x86-64
>>
>>
>> Disassembly of section .init:
>>
>> 00401000 <_init>:
>>   401000:   f3 0f 1e fa endbr64
>>   401004:   48 83 ec 08 sub$0x8,%rsp
>>   401008:   48 8b 05 d1 2f 00 00mov0x2fd1(%rip),%rax#
>> 403fe0 <__gmon_start__@Base>
>>   40100f:   48 85 c0test   %rax,%rax
>>   401012:   74 02   je 401016 <_init+0x16>
>>   401014:   ff d0   call   *%rax
>>   401016:   48 83 c4 08 add$0x8,%rsp
>>   40101a:   c3  ret
>>
>> Disassembly of section .text:
>>
>> 00401020 <_start>:
>>   401020:   f3 0f 1e fa endbr64
>>   401024:   31 ed   xor%ebp,%ebp
>>   401026:   49 89 d1mov%rdx,%r9
>>   401029:   5e  pop%rsi
>>   40102a:   48 89 e2mov%rsp,%rdx
>>   40102d:   48 83 e4 f0 and$0xfff0,%rsp
>>   401031:   50  push   %rax
>>   401032:   54  push   %rsp
>>   401033:   45 31 c0xor%r8d,%r8d
>>   401036:   31 c9   xor%ecx,%ecx
>>   401038:   48 c7 c7 06 11 40 00mov$0x401106,%rdi
>>   40103f:   ff 15 93 2f 00 00   call   *0x2f93(%rip)#
>> 403fd8 <__libc_start_main@GLIBC_2.34>
>>   401045:   f4  hlt
>>   401046:   66 2e 0f 1f 84 00 00cs nopw 0x0(%rax,%rax,1)
>>   40104d:   00 00 00
>> (.)
>>
>> Basically, its not *really* a totally null program.  You've got the
>> dynamic
>> loader ld-linux running first, which then *doesn't* run main() directly,
>> but
>> rather invokes _start, which needs to happen so that __libc_start_main
>> can get
>> called and initialize stuff lie stdio, malloc, and other such t hings,
>> before
>> it finally calls main().
>>
>> Personally, I'm surprised that ld-linux and glibc initialization can
>> finish
>> without going over 500k - even more so if shared library text pages are
>> included in memory.peak.  Somebody  else can wade into that mess, I admit
>> having been around since kernel 2.5.47 or so, and I never did understand
>> the
>> memory accounting for shared text pages
>>
>>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: How to accout max_rss precisely

2024-06-03 Thread Valdis Klētnieks
On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said:

> // a.c
> int main() {}
>
> It shows that `memory.peak` of this program is ~500KiB, which does not make
> sense to me.

Makes sense to me...

[~] cat > testnull.c
 int main() {}
[~] gcc testnull.c
[~] ldd a.out
linux-vdso.so.1 (0x7efc6a65)
libc.so.6 => /lib64/libc.so.6 (0x7efc6a43d000)
/lib64/ld-linux-x86-64.so.2 (0x7efc6a652000)
[~] objdump -d a.out

a.out: file format elf64-x86-64


Disassembly of section .init:

00401000 <_init>:
  401000:   f3 0f 1e fa endbr64
  401004:   48 83 ec 08 sub$0x8,%rsp
  401008:   48 8b 05 d1 2f 00 00mov0x2fd1(%rip),%rax# 
403fe0 <__gmon_start__@Base>
  40100f:   48 85 c0test   %rax,%rax
  401012:   74 02   je 401016 <_init+0x16>
  401014:   ff d0   call   *%rax
  401016:   48 83 c4 08 add$0x8,%rsp
  40101a:   c3  ret

Disassembly of section .text:

00401020 <_start>:
  401020:   f3 0f 1e fa endbr64
  401024:   31 ed   xor%ebp,%ebp
  401026:   49 89 d1mov%rdx,%r9
  401029:   5e  pop%rsi
  40102a:   48 89 e2mov%rsp,%rdx
  40102d:   48 83 e4 f0 and$0xfff0,%rsp
  401031:   50  push   %rax
  401032:   54  push   %rsp
  401033:   45 31 c0xor%r8d,%r8d
  401036:   31 c9   xor%ecx,%ecx
  401038:   48 c7 c7 06 11 40 00mov$0x401106,%rdi
  40103f:   ff 15 93 2f 00 00   call   *0x2f93(%rip)# 403fd8 
<__libc_start_main@GLIBC_2.34>
  401045:   f4  hlt
  401046:   66 2e 0f 1f 84 00 00cs nopw 0x0(%rax,%rax,1)
  40104d:   00 00 00
(.)

Basically, its not *really* a totally null program.  You've got the dynamic
loader ld-linux running first, which then *doesn't* run main() directly, but
rather invokes _start, which needs to happen so that __libc_start_main can get
called and initialize stuff lie stdio, malloc, and other such t hings, before
it finally calls main().

Personally, I'm surprised that ld-linux and glibc initialization can finish
without going over 500k - even more so if shared library text pages are
included in memory.peak.  Somebody  else can wade into that mess, I admit
having been around since kernel 2.5.47 or so, and I never did understand the
memory accounting for shared text pages



pgpwnrcm6vesq.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

2024-05-17 Thread jim . cromie
On Thu, May 9, 2024 at 8:39 AM Muni Sekhar  wrote:
>
> Dear Linux Kernel Community,
>
> I am reaching out to seek assistance regarding the usage of spin locks
> in the Linux kernel and to address a recurring issue related to hard
> LOCKUP errors that I have encountered during testing.
>

build your kernel with LOCKDEP everything ?


> Recently, I developed a small kernel module that involves ISR handling
> and utilizes the spinlock_t primitive. In my module, I have employed
> spin locks both in process context using spin_lock() and spin_unlock()
> APIs, as well as in ISR context using spin_lock_irqsave() and
> spin_unlock_irqrestore() APIs.
>
> Here is a brief overview of how I have implemented spin locks in my module:
>

I certainly dont know whether the above and below are legal.
Id be comparing my usage to working examples from the source-code.

and you didnt say anything about your module or what it does.
(fwiw, you'd get more help if it were "our" module, ie gpl'd)



> However, during testing, I have encountered a scenario where a hard
> LOCKUP (NMI watchdog: Watchdog detected hard LOCKUP on cpu 2) error
> occurs, specifically when a process context code execution triggers
> the spin_lock() function and is preempted by an interrupt that enters
> the ISR context and encounters the spin_lock_irqsave() function. This
> situation leads to the CPU being stuck indefinitely.
>

Id build w/o watchdog, to see what else goes wrong.
2 different errors might help find common cause.



> My primary concern is to understand the appropriate usage of spin
> locks in both process and ISR contexts to avoid such hard LOCKUP
> errors. I am seeking clarification on the following points:
>

Documentation/locking/hwspinlock.rst

> Is it safe to use spin_lock_irqsave() and spin_unlock_irqrestore()
> APIs in ISR context and spin_lock() and spin_unlock() APIs in process
> context simultaneously?
> In scenarios where a process context code execution is preempted
> by an interrupt and enters ISR context, how should spin locks be used
> to prevent hard LOCKUP errors?
> Are there any specific guidelines or best practices for using spin
> locks in scenarios involving both process and ISR contexts?
>
> I would greatly appreciate any insights, guidance, or suggestions from
> the experienced members of the Linux kernel community to help address
> this issue and ensure the correct and efficient usage of spin locks in
> my kernel module.
>
> Thank you very much for your time and assistance.
>
> --
> Thanks,
> Sekhar
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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


Re: Handling I2C eeprom devices

2024-05-17 Thread jim . cromie
On Fri, May 17, 2024 at 7:35 AM Patryk  wrote:
>
> Hi,
> I've got a question regarding how to handle I2C eeprom devices. I see
> that in the kernel/drivers/misc/eeprom there are not that many drivers
> available. Does it mean that they support various chips that do not
> necessarily come from one vendor?
> Looking at example at24.c, in the compatible properties I see that all
> of them refers to atmel, however when I compared the following
> devices: AT24C04C and BRCB008GWZ, at the first glance they look kinda
> similar:
> - they are organized internally in the same way - 1024 x 8 (8K)
> - read/write commands looks the same
>
> I'm not asking you to tell me whether or not it's possible this driver
> at24 with the device I need (BRCB008GWZ), rather I would like to get a
> suggestion on how to approach this and what factors I should take into
> account to make the right decision.
>
> Best regards
> Patryk
>

$ git ls-files | grep eprom | wc -l
89
[jimc@frodo linux.git]$ git ls-files | grep eprom\.h | wc -l
29
[jimc@frodo linux.git]$ git ls-files | grep eprom  | grep include
arch/parisc/include/asm/eisa_eeprom.h
arch/sparc/include/asm/eeprom.h
drivers/staging/rtl8723bs/include/rtw_eeprom.h
include/linux/eeprom_93cx6.h
include/linux/eeprom_93xx46.h
include/linux/spi/eeprom.h
include/media/tveeprom.h

Id look at those headers for similarity,
then the 2 c files in misc for similarity.

also the files under devicetree - thats ALL interface defn

you didnt say if those parts are I2C or SPI or what.

do you have the hardware ?

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


Re: Handling I2C eeprom devices

2024-05-17 Thread Rémi ESSAISSI



Le 17/05/2024 à 15:33, Patryk a écrit :

Hi,
I've got a question regarding how to handle I2C eeprom devices. I see
that in the kernel/drivers/misc/eeprom there are not that many drivers
available. Does it mean that they support various chips that do not
necessarily come from one vendor?
Looking at example at24.c, in the compatible properties I see that all
of them refers to atmel, however when I compared the following
devices: AT24C04C and BRCB008GWZ, at the first glance they look kinda
similar:
- they are organized internally in the same way - 1024 x 8 (8K)





- read/write commands looks the same
Those chips may look the "same", but they differ in the magic sequences 
to interact with them.
I mean, they have to be exactly the same to work, up to the timing that 
has to follow the specs by the milli or micro second for example.

(and sometimes even weird voltages to apply on this or that pin ... )

So your best friend is the Datasheet of your IC delivered by the 
vendor/constructor of that chip, that will give you the magic sequences 
to interact with it .


Your case should be easy as you already have more than a working 
"skeleton" ... .



Regards




I'm not asking you to tell me whether or not it's possible this driver
at24 with the device I need (BRCB008GWZ), rather I would like to get a
suggestion on how to approach this and what factors I should take into
account to make the right decision.

Best regards
Patryk

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


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


Re: [RFC PATCH] kvm: replace spaces with a tab

2024-05-16 Thread Greg KH
On Thu, May 16, 2024 at 10:31:45AM +0100, Mohamed Karaoui wrote:
> Hi list,
> 
> This is an attempt to get a feeling of sending a first patch. Please feel
> free to comment.
> 
> I have few questions:
> 
> - I have build this patch against the torvalds/linux.git. Does it matter
> which tree I use as long as it works on the maintainer tree?
> 
> - In this particular case I checked the maintainer. It seems that its
> tree is something of 11 years old.

I suggest working on drivers/staging/ first for basic coding style fixes
like this, as they are encouraged there, but not necessarily in other
parts of the kerenel at all.

Good luck!

greg k-h

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


Re: Looking for advise

2024-05-15 Thread Rémi ESSAISSI


Well :) you asked for it !


We are some Linux users stuck with a USB/VGA-HDMI device,


the FL2000 : https://github.com/FrescoLogic/FL2000



the driver "did" work once (kernel version)


Perso I havent had the time yet to read that book .


I am sure more than one will thank you if you could look at it, me one 
of them !







Le 15/05/2024 à 13:50, Jules Irenge a écrit :
I am looking for advice on what to do after reading the Linux device 
driver book.


Someone suggests I get a beaglebone and write some i2c driver to get 
hands-on experience,

I will consider that.

Any other suggestion will be appreciated

Thanks,
Jules
*..
*
Open source contributor: https://bit.ly/40GblaQ 
Blog: https:// 
www.julesirenge.blog

twitter: @jules_irenge
strava: https://www.strava.com/athletes/72390635 

linkedIn: _https://www.linkedin.com/in/jules-irenge-87282238/ 
_


**

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


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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-13 Thread Alan Stern
On Mon, May 13, 2024 at 11:14:44PM +0530, Muni Sekhar wrote:
> In the context of the Linux kernel and USB devices, what are the
> similarities and differences between usbfs and sysfs?

They are totally different.  usbfs gives you direct communication with 
the various USB devices on your system.  sysfs presents interfaces for 
monitoring and controlling your entire system (including information 
about how it manages its USB devices) but doesn't provide a way to 
communicate with the devices.

> Before invoking the ioctl() system call, we need to obtain a file
> descriptor by invoking the open() system call. How do we identify the
> device node in the usbfs interface?
> For example, can you please explain how to identify the device node
> location of a Human Interface Device(shown below in lsusb -t output)
> as the first argument in the open() system call.
> 
> $ lsusb -t
> /:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
> /:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M
> /:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M
> |__ Port 002: Dev 003, If 0, Class=Human Interface Device, 
> Driver=usbhid, 1.5M
> /:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M
> /:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M

The Human Interface Device is Device 003 on Bus 004.  Therefore the 
device node is /dev/bus/usb/004/003.

Alan Stern

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-13 Thread Muni Sekhar
On Tue, May 7, 2024 at 5:14 PM Muni Sekhar  wrote:
>
> On Tue, May 7, 2024 at 1:20 AM Alan Stern  wrote:
> >
> > On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote:
> > > On Mon, May 6, 2024 at 7:59 PM Alan Stern  
> > > wrote:
> > > >
> > > > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
> > > > > While we have successfully converted most of the USB device driver
> > > > > functionality from kernel space to user space using libusb, we are now
> > > > > seeking guidance on how to implement USB device suspend/resume in user
> > > > > space. Specifically, we would like to know if libusb provides support
> > > > > for achieving the suspend/resume functionality mentioned above.
> > > > > Additionally, any insights or suggestions on how to accomplish this
> > > > > task would be greatly appreciated.
> > > >
> > > > Your question is about libusb, right?  So you'll get better answers if
> > > > you post it on the libusb mailing list rather than the linux-usb mailing
> > > > list.
> > > Can USB device suspend\resume  be implemented in user space driver
> > > using software other than libusb?
> >
> > Yes, a userspace driver can use the usbfs interface and can employ the
> > ioctl commands listed in /usr/include/linux/usbdevfs.h.  It's possible

In the context of the Linux kernel and USB devices, what are the
similarities and differences between usbfs and sysfs?
Before invoking the ioctl() system call, we need to obtain a file
descriptor by invoking the open() system call. How do we identify the
device node in the usbfs interface?
For example, can you please explain how to identify the device node
location of a Human Interface Device(shown below in lsusb -t output)
as the first argument in the open() system call.

$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 002: Dev 003, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M


> > that libusb also provides facilities for controlling suspend and resume;
> > I don't know whether it does.
> >
> > > If so, what are those methods or techniques to achieve USB device
> > > suspend\resume , can you please provide clarity on this.
> >
> > As far as I know, these usbfs ioctl commands are not documented
> > anywhere.
> >
> > The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being
> > suspended, and wakes it up if it is currently suspended.
> >
> > The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended.  The
> > suspend may not happen immediately; it is controlled by the settings in
> > the device's power/control and power/autosuspend (or
> > power/autosuspend_delay_ms) sysfs attribute files.
> >
> > The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes,
> > whether because of a remote wakeup or because another process has
> > resumed it, and then forbids the device from suspending again until
> > you perform another USBDEVFS_ALLOW_SUSPEND ioctl.
> >
> Thank you, it is very helpful.
>
> To verify the USB device suspend\resume functionality, I configured
> the USB Power Management variables as follows:
>
> # cat /sys/bus/usb/devices/2-1.7/power/wakeup
> enabled
>
> # cat /sys/bus/usb/devices/2-1.7/power/control
> on
>
> # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms
> 0
>
> # cat /sys/module/usbcore/parameters/autosuspend
> 2
>
>
> So, I configured the system to autosuspend the USB device as soon as
> it becomes idle, with no transactions running through the USB device.
> Now, how can I verify that the USB device has entered suspend mode
> from user space? When checking /var/log/kern.log, there are no
> relevant print statements. Are there any other log files related to
> power management or USB subsystems?
> Please correct me if anything in the test procedure mentioned above is
> incorrect.
>
> > Alan Stern
>
>
>
> --
> Thanks,
> Sekhar



-- 
Thanks,
Sekhar

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


Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

2024-05-10 Thread Muni Sekhar
On Thu, May 9, 2024 at 11:27 PM Billie Alsup (balsup)  wrote:
>
> >From: Muni Sekhar 
> >In the scenario where an interrupt occurs while we are servicing the
> >interrupt, and in the scenario where it doesn't occur while we are
> >servicing the interrupt, when should we use the
> >spin_lock_irqsave/spin_unlock_irqrestore APIs?
>
> In my experience, the interrupts are masked by the infrastructure before 
> invoking the
> interrupt service routine.  So unless you explicitly re-enable them, there 
> shouldn't be
> a nested interrupt for the same interrupt number.
>
> It is the code run at process context that must be protected using the 
> irqsave/irqrestore
> versions.  You want to not only enter the critical section, but also prevent
> the interrupt from occurring (on the same cpu at least).  If you enter the 
> critical section in
> process context, but then take an interrupt and attempt to again enter the
> critical section, then your interrupt routine will deadlock. the interrupt 
> routine will never
> be able to acquire the lock, and the process context code that was 
> interrupted will never be
> able to complete to release the lock.  So the process context code requires 
> the
> irqsave/irqrestore variant to not only take the lock, but also prevent a 
> competing interrupt
> routine from being triggered while you hold the lock.
>
> Bottom line is that if a critical section can be entered via both process 
> context
> and interrupt context, then the process context invocation should use the 
> irqsave/irqrestore
> variants to disable the interrupt before taking the lock.  If it is common 
> code shared between
> process context and interrupt context, then there is no harm in calling the 
> irqsave/irqrestore
> version from both contexts.
Thanks a lot for the detailed clarification.
>
> Otherwise, the standard spin_lock/spin_unlock variants (without 
> irqsave/irqrestore) would be
> used for a critical section shared by multiple threads (different cpus), or 
> when your code has
> already (separately) handled disabling interrupts as needed before invoking 
> spin_lock.
>
>


-- 
Thanks,
Sekhar

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


Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

2024-05-09 Thread Billie Alsup (balsup)
>From: Muni Sekhar 
>In the scenario where an interrupt occurs while we are servicing the
>interrupt, and in the scenario where it doesn't occur while we are
>servicing the interrupt, when should we use the
>spin_lock_irqsave/spin_unlock_irqrestore APIs?

In my experience, the interrupts are masked by the infrastructure before 
invoking the
interrupt service routine.  So unless you explicitly re-enable them, there 
shouldn't be
a nested interrupt for the same interrupt number.

It is the code run at process context that must be protected using the 
irqsave/irqrestore
versions.  You want to not only enter the critical section, but also prevent
the interrupt from occurring (on the same cpu at least).  If you enter the 
critical section in
process context, but then take an interrupt and attempt to again enter the
critical section, then your interrupt routine will deadlock. the interrupt 
routine will never 
be able to acquire the lock, and the process context code that was interrupted 
will never be
able to complete to release the lock.  So the process context code requires the
irqsave/irqrestore variant to not only take the lock, but also prevent a 
competing interrupt
routine from being triggered while you hold the lock.

Bottom line is that if a critical section can be entered via both process 
context
and interrupt context, then the process context invocation should use the 
irqsave/irqrestore
variants to disable the interrupt before taking the lock.  If it is common code 
shared between
process context and interrupt context, then there is no harm in calling the 
irqsave/irqrestore
version from both contexts.

Otherwise, the standard spin_lock/spin_unlock variants (without 
irqsave/irqrestore) would be
used for a critical section shared by multiple threads (different cpus), or 
when your code has
already (separately) handled disabling interrupts as needed before invoking 
spin_lock.



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


Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

2024-05-09 Thread Muni Sekhar
On Thu, May 9, 2024 at 8:56 PM Billie Alsup (balsup)  wrote:
>
> >From: Muni Sekhar 
>
> >Here is a brief overview of how I have implemented spin locks in my module:
> >
> >spinlock_t my_spinlock; // Declare a spin lock
> >
> >// In ISR context (interrupt handler):
> >spin_lock_irqsave(&my_spinlock, flags);
> >// ... Critical section ...
> >spin_unlock_irqrestore(&my_spinlock, flags);
> >
> >
> >// In process context: (struct file_operations.read)
> >spin_lock(&my_spinlock);
> >// ... Critical section ...
> >spin_unlock(&my_spinlock);
>
> from my understanding, you have the usage backwards.  It is the 
> irqsave/irqrestore versions that should be used within process context to 
> prevent the interrupt from being handled on the same cpu while executing in 
> your critical section.
>
> The use of irqsave/irqrestore within the isr itself is ok, although perhaps 
> unnecessary.  It depends on whether the interrupt can occur again while you 
> are servicing the interrupt (whether on this cpu or another).  Usually (?) 
> the same interrupt does not nest, unless you have explicitly coded to allow 
> it (for example, by acknowledging and re-enabling the interrupt early in your 
> ISR). Certainly the spinlock is necessary to protect the critical section 
> from running in an isr on one cpu and process space on another cpu.
>
In the scenario where an interrupt occurs while we are servicing the
interrupt, and in the scenario where it doesn't occur while we are
servicing the interrupt, when should we use the
spin_lock_irqsave/spin_unlock_irqrestore APIs?
> From a lockup perspective, not doing the irqsave/irqrestore from process 
> context could explain your problem. Also look for code (anywhere!) that 
> blindly enables interrupts, rather than doing irqrestore from a prior irqsave.



-- 
Thanks,
Sekhar

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


Re: Seeking Assistance with Spin Lock Usage and Resolving Hard LOCKUP Error

2024-05-09 Thread Billie Alsup (balsup)
>From: Muni Sekhar 

>Here is a brief overview of how I have implemented spin locks in my module:
>
>spinlock_t my_spinlock; // Declare a spin lock
>
>// In ISR context (interrupt handler):
>spin_lock_irqsave(&my_spinlock, flags);
>// ... Critical section ...
>spin_unlock_irqrestore(&my_spinlock, flags);
>
>
>// In process context: (struct file_operations.read)
>spin_lock(&my_spinlock);
>// ... Critical section ...
>spin_unlock(&my_spinlock);

from my understanding, you have the usage backwards.  It is the 
irqsave/irqrestore versions that should be used within process context to 
prevent the interrupt from being handled on the same cpu while executing in 
your critical section.

The use of irqsave/irqrestore within the isr itself is ok, although perhaps 
unnecessary.  It depends on whether the interrupt can occur again while you are 
servicing the interrupt (whether on this cpu or another).  Usually (?) the same 
interrupt does not nest, unless you have explicitly coded to allow it (for 
example, by acknowledging and re-enabling the interrupt early in your ISR). 
Certainly the spinlock is necessary to protect the critical section from 
running in an isr on one cpu and process space on another cpu.

>From a lockup perspective, not doing the irqsave/irqrestore from process 
>context could explain your problem. Also look for code (anywhere!) that 
>blindly enables interrupts, rather than doing irqrestore from a prior irqsave.

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


Re: Submitting a selftest patch

2024-05-08 Thread Tom Mitchell
Ask the maintainers!
In an ideal world there would be a directory or package of self tests
associated with the subsystem.

Alternatively:
If you have an account on git make a "My work is GPL3" statement file
then clone or fork and add your patch and
add the self test. A personal fork gives you a playground, you can
merge it back or just flush.

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

On Tue, May 7, 2024 at 7:39 PM Camila Alvarez  wrote:
>
> I’ve been discussing a bug with one of the maintainers of a subsystem. At one 
> point I was asked to craft a selftest for the issue.
>
> My question is: how do I send the patch with the selftest? Do I need to 
> reference the email where the selftest request was made? Or should I just 
> send it as an independent patch?
>
> Thanks in advance
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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


Re: Submitting a selftest patch

2024-05-08 Thread Siddh Raman Pant
On Wed, 08 May 2024 08:08:20 +0530 Camila Alvarez  wrote:
> I’ve been discussing a bug with one of the maintainers of a subsystem.
> At one point I was asked to craft a selftest for the issue. 
>  
> My question is: how do I send the patch with the selftest? Do I need
> to reference the email where the selftest request was made? Or
> should I just send it as an independent patch? 

Both are fine. git send-email has in-reply-to option so you can just
reply to the thread. Make sure to CC the relevant mailing lists and
people.

Thanks,
Siddh

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


Re: Submitting a selftest patch

2024-05-08 Thread Jules Irenge
That 's cool. I would send a patch then a selftest separately but could ask
the maintainer.
Jules Irenge
Open source contributor: https://bit.ly/40GblaQ
Blog: https:// 
www.julesirenge.blog
twitter: @jules_irenge
strava: https://www.strava.com/athletes/72390635
linkedIn: *https://www.linkedin.com/in/jules-irenge-87282238/
*



On Wed, 8 May 2024 at 03:39, Camila Alvarez  wrote:

> I’ve been discussing a bug with one of the maintainers of a subsystem. At
> one point I was asked to craft a selftest for the issue.
>
> My question is: how do I send the patch with the selftest? Do I need to
> reference the email where the selftest request was made? Or should I just
> send it as an independent patch?
>
> Thanks in advance
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-08 Thread Alan Stern
On Wed, May 08, 2024 at 11:08:11AM +0530, Muni Sekhar wrote:
> Thank you for the clear explanation on how to identify devices
> associated with root hubs.
> Could you please provide clarity on whether the root hub devices have
> attribute files in the devices sysfs directory? Upon checking the
> sysfs directory, I couldn't find any relevant information about these
> attribute files.

Root hubs have different names in sysfs from all other USB devices.  The 
root hub on bus N is named "usbN".  For example, the root hub on bus 4 
is named "usb4".

Alan Stern

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-07 Thread Muni Sekhar
On Tue, May 7, 2024 at 11:21 PM Alan Stern  wrote:
>
> On Tue, May 07, 2024 at 10:08:13PM +0530, Muni Sekhar wrote:
> > Now, I can verify USB device auto-suspend and auto-resume through the
> > kernel log.
> >
> > In my test system, I found three buses "Bus 001, 002, and 003" using
> > the lsusb command.
> >
> > The USB device I want to test is located on "Bus 002".
> >
> >
> > # lsusb | grep "Bus 002" | wc
> >   4  37 224
> >
> > As per the output of the above command, there are 4 USB devices on
> > "Bus 002" in my test system.
> >
> >
> > # ls -l /sys/bus/usb/devices/2*
> > lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 ->
> > ../../../devices/pci:00/:00:14.0/usb2/2-0:1.0
> > lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1 ->
> > ../../../devices/pci:00/:00:14.0/usb2/2-1
> > lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.1 ->
> > ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1
> > lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1:1.0 ->
> > ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0
> > lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.1:1.0
> > -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0
> > lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.7 ->
> > ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7
> > lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.7:1.0
> > -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0
> >
> > # ls -l /sys/bus/usb/devices/2* | wc
> >   7  77 892
> >
> >
> > The above command shows seven nodes in /sys/bus/usb/devices/2* directory.
> >
> > The wakeup, control, and autosuspend_delay_ms attribute files are
> > controlled via /sys/bus/usb/devices/.../power/, where "..." represents
> > the device's ID.
> >
> > I identified my test device in /sys/bus/usb/devices/.../power/ by
> > iterating through all the directories, reading the idVendor attribute
> > file, and then manipulating the power management attribute files.
> >
> > Is there a way to manually map /sys/bus/usb/devices/.../power/ from
> > the lsusb output? Can this mapping be done from a user space program
> > as well? Do you have any reference examples for this? If so, could you
> > share their GitHub location?
>
> libusb already can do this for you.
>
> However, if you want to do it by hand then you can match up devices
> based on the devnum attribute file in the devices sysfs directory.  For
> example, if you were trying to identify which device corresonds to the
> lsusb entry for device 003 on bus 002, you should look through all the
> directories in /sys/bus/usb/devices/2-* and see which one has "3" in its
> devnum file.
>
> There's another way of doing it more directly, using the output from
> "lsusb -t".  For example, on my system:
>
> $ lsusb -t
> /:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
> /:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M
> /:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M
> |__ Port 002: Dev 003, If 0, Class=Human Interface Device, 
> Driver=usbhid, 1.5M
> /:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
> /:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M
> /:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M
>
> Let's say we want to locate the Human Interface Device in sysfs.
> According to the listing, it is on port 002 below port 001 below bus
> 004.  You reverse the numbers, put a '-' after the bus number,
> and separate the port numbers with a '.', which gives "4-1.2":
>
> $ cat /sys/bus/usb/devices/4-1.2/product
> Microsoft 5-Button Mouse with IntelliEye(TM)
Thank you for the clear explanation on how to identify devices
associated with root hubs.
Could you please provide clarity on whether the root hub devices have
attribute files in the devices sysfs directory? Upon checking the
sysfs directory, I couldn't find any relevant information about these
attribute files.
Thank you again for your assistance.

>
> Alan Stern



-- 
Thanks,
Sekhar

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-07 Thread Alan Stern
On Tue, May 07, 2024 at 10:08:13PM +0530, Muni Sekhar wrote:
> Now, I can verify USB device auto-suspend and auto-resume through the
> kernel log.
> 
> In my test system, I found three buses "Bus 001, 002, and 003" using
> the lsusb command.
> 
> The USB device I want to test is located on "Bus 002".
> 
> 
> # lsusb | grep "Bus 002" | wc
>   4  37 224
> 
> As per the output of the above command, there are 4 USB devices on
> "Bus 002" in my test system.
> 
> 
> # ls -l /sys/bus/usb/devices/2*
> lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 ->
> ../../../devices/pci:00/:00:14.0/usb2/2-0:1.0
> lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1 ->
> ../../../devices/pci:00/:00:14.0/usb2/2-1
> lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.1 ->
> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1
> lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1:1.0 ->
> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0
> lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.1:1.0
> -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0
> lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.7 ->
> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7
> lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.7:1.0
> -> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0
> 
> # ls -l /sys/bus/usb/devices/2* | wc
>   7  77 892
> 
> 
> The above command shows seven nodes in /sys/bus/usb/devices/2* directory.
> 
> The wakeup, control, and autosuspend_delay_ms attribute files are
> controlled via /sys/bus/usb/devices/.../power/, where "..." represents
> the device's ID.
> 
> I identified my test device in /sys/bus/usb/devices/.../power/ by
> iterating through all the directories, reading the idVendor attribute
> file, and then manipulating the power management attribute files.
> 
> Is there a way to manually map /sys/bus/usb/devices/.../power/ from
> the lsusb output? Can this mapping be done from a user space program
> as well? Do you have any reference examples for this? If so, could you
> share their GitHub location?

libusb already can do this for you.

However, if you want to do it by hand then you can match up devices 
based on the devnum attribute file in the devices sysfs directory.  For 
example, if you were trying to identify which device corresonds to the 
lsusb entry for device 003 on bus 002, you should look through all the 
directories in /sys/bus/usb/devices/2-* and see which one has "3" in its 
devnum file.

There's another way of doing it more directly, using the output from 
"lsusb -t".  For example, on my system:

$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 002: Dev 003, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M

Let's say we want to locate the Human Interface Device in sysfs.  
According to the listing, it is on port 002 below port 001 below bus 
004.  You reverse the numbers, put a '-' after the bus number, 
and separate the port numbers with a '.', which gives "4-1.2":

$ cat /sys/bus/usb/devices/4-1.2/product
Microsoft 5-Button Mouse with IntelliEye(TM)

Alan Stern

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-07 Thread Muni Sekhar
On Tue, May 7, 2024 at 7:50 PM Alan Stern  wrote:
>
> On Tue, May 07, 2024 at 05:14:25PM +0530, Muni Sekhar wrote:
> > Thank you, it is very helpful.
> >
> > To verify the USB device suspend\resume functionality, I configured
> > the USB Power Management variables as follows:
> >
> > # cat /sys/bus/usb/devices/2-1.7/power/wakeup
> > enabled
> >
> > # cat /sys/bus/usb/devices/2-1.7/power/control
> > on
>
> This means that the device will be permanently on, and so it will never
> be suspended.  If you want to allow the device to be suspended, you
> have to write "auto" to the file.
Thanks a lot for these inputs.
Now, I can verify USB device auto-suspend and auto-resume through the
kernel log.

In my test system, I found three buses "Bus 001, 002, and 003" using
the lsusb command.

The USB device I want to test is located on "Bus 002".


# lsusb | grep "Bus 002" | wc
  4  37 224

As per the output of the above command, there are 4 USB devices on
"Bus 002" in my test system.


# ls -l /sys/bus/usb/devices/2*
lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 ->
../../../devices/pci:00/:00:14.0/usb2/2-0:1.0
lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1 ->
../../../devices/pci:00/:00:14.0/usb2/2-1
lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.1 ->
../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1
lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1:1.0 ->
../../../devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0
lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.1:1.0
-> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0
lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.7 ->
../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7
lrwxrwxrwx 1 root root 0 May  7 13:16 /sys/bus/usb/devices/2-1.7:1.0
-> ../../../devices/pci:00/:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0

# ls -l /sys/bus/usb/devices/2* | wc
  7  77 892


The above command shows seven nodes in /sys/bus/usb/devices/2* directory.

The wakeup, control, and autosuspend_delay_ms attribute files are
controlled via /sys/bus/usb/devices/.../power/, where "..." represents
the device's ID.

I identified my test device in /sys/bus/usb/devices/.../power/ by
iterating through all the directories, reading the idVendor attribute
file, and then manipulating the power management attribute files.

Is there a way to manually map /sys/bus/usb/devices/.../power/ from
the lsusb output? Can this mapping be done from a user space program
as well? Do you have any reference examples for this? If so, could you
share their GitHub location?


>
> > # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms
> > 0
> >
> > # cat /sys/module/usbcore/parameters/autosuspend
> > 2
> >
> >
> > So, I configured the system to autosuspend the USB device as soon as
> > it becomes idle, with no transactions running through the USB device.
> > Now, how can I verify that the USB device has entered suspend mode
> > from user space? When checking /var/log/kern.log, there are no
> > relevant print statements. Are there any other log files related to
> > power management or USB subsystems?
> > Please correct me if anything in the test procedure mentioned above is
> > incorrect.
>
> You can see the device's current state by reading the
> power/runtime_status attribute file in sysfs.  There are lots of other
> informative files in that directory; you should look at them.
>
> If you want to get more debugging information in the kernel log, you can
> enable dynamic debugging for usbcore:
>
> echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
>
> Alan Stern



-- 
Thanks,
Sekhar

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-07 Thread Alan Stern
On Tue, May 07, 2024 at 05:14:25PM +0530, Muni Sekhar wrote:
> Thank you, it is very helpful.
> 
> To verify the USB device suspend\resume functionality, I configured
> the USB Power Management variables as follows:
> 
> # cat /sys/bus/usb/devices/2-1.7/power/wakeup
> enabled
> 
> # cat /sys/bus/usb/devices/2-1.7/power/control
> on

This means that the device will be permanently on, and so it will never 
be suspended.  If you want to allow the device to be suspended, you 
have to write "auto" to the file.

> # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms
> 0
> 
> # cat /sys/module/usbcore/parameters/autosuspend
> 2
> 
> 
> So, I configured the system to autosuspend the USB device as soon as
> it becomes idle, with no transactions running through the USB device.
> Now, how can I verify that the USB device has entered suspend mode
> from user space? When checking /var/log/kern.log, there are no
> relevant print statements. Are there any other log files related to
> power management or USB subsystems?
> Please correct me if anything in the test procedure mentioned above is
> incorrect.

You can see the device's current state by reading the 
power/runtime_status attribute file in sysfs.  There are lots of other 
informative files in that directory; you should look at them.

If you want to get more debugging information in the kernel log, you can 
enable dynamic debugging for usbcore:

echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control

Alan Stern

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-07 Thread Muni Sekhar
On Tue, May 7, 2024 at 1:20 AM Alan Stern  wrote:
>
> On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote:
> > On Mon, May 6, 2024 at 7:59 PM Alan Stern  wrote:
> > >
> > > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
> > > > While we have successfully converted most of the USB device driver
> > > > functionality from kernel space to user space using libusb, we are now
> > > > seeking guidance on how to implement USB device suspend/resume in user
> > > > space. Specifically, we would like to know if libusb provides support
> > > > for achieving the suspend/resume functionality mentioned above.
> > > > Additionally, any insights or suggestions on how to accomplish this
> > > > task would be greatly appreciated.
> > >
> > > Your question is about libusb, right?  So you'll get better answers if
> > > you post it on the libusb mailing list rather than the linux-usb mailing
> > > list.
> > Can USB device suspend\resume  be implemented in user space driver
> > using software other than libusb?
>
> Yes, a userspace driver can use the usbfs interface and can employ the
> ioctl commands listed in /usr/include/linux/usbdevfs.h.  It's possible
> that libusb also provides facilities for controlling suspend and resume;
> I don't know whether it does.
>
> > If so, what are those methods or techniques to achieve USB device
> > suspend\resume , can you please provide clarity on this.
>
> As far as I know, these usbfs ioctl commands are not documented
> anywhere.
>
> The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being
> suspended, and wakes it up if it is currently suspended.
>
> The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended.  The
> suspend may not happen immediately; it is controlled by the settings in
> the device's power/control and power/autosuspend (or
> power/autosuspend_delay_ms) sysfs attribute files.
>
> The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes,
> whether because of a remote wakeup or because another process has
> resumed it, and then forbids the device from suspending again until
> you perform another USBDEVFS_ALLOW_SUSPEND ioctl.
>
Thank you, it is very helpful.

To verify the USB device suspend\resume functionality, I configured
the USB Power Management variables as follows:

# cat /sys/bus/usb/devices/2-1.7/power/wakeup
enabled

# cat /sys/bus/usb/devices/2-1.7/power/control
on

# cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms
0

# cat /sys/module/usbcore/parameters/autosuspend
2


So, I configured the system to autosuspend the USB device as soon as
it becomes idle, with no transactions running through the USB device.
Now, how can I verify that the USB device has entered suspend mode
from user space? When checking /var/log/kern.log, there are no
relevant print statements. Are there any other log files related to
power management or USB subsystems?
Please correct me if anything in the test procedure mentioned above is
incorrect.

> Alan Stern



-- 
Thanks,
Sekhar

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-06 Thread Alan Stern
On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote:
> On Mon, May 6, 2024 at 7:59 PM Alan Stern  wrote:
> >
> > On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
> > > While we have successfully converted most of the USB device driver
> > > functionality from kernel space to user space using libusb, we are now
> > > seeking guidance on how to implement USB device suspend/resume in user
> > > space. Specifically, we would like to know if libusb provides support
> > > for achieving the suspend/resume functionality mentioned above.
> > > Additionally, any insights or suggestions on how to accomplish this
> > > task would be greatly appreciated.
> >
> > Your question is about libusb, right?  So you'll get better answers if
> > you post it on the libusb mailing list rather than the linux-usb mailing
> > list.
> Can USB device suspend\resume  be implemented in user space driver
> using software other than libusb?

Yes, a userspace driver can use the usbfs interface and can employ the 
ioctl commands listed in /usr/include/linux/usbdevfs.h.  It's possible 
that libusb also provides facilities for controlling suspend and resume; 
I don't know whether it does.

> If so, what are those methods or techniques to achieve USB device
> suspend\resume , can you please provide clarity on this.

As far as I know, these usbfs ioctl commands are not documented 
anywhere.

The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being 
suspended, and wakes it up if it is currently suspended.

The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended.  The 
suspend may not happen immediately; it is controlled by the settings in 
the device's power/control and power/autosuspend (or 
power/autosuspend_delay_ms) sysfs attribute files.

The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes, 
whether because of a remote wakeup or because another process has 
resumed it, and then forbids the device from suspending again until 
you perform another USBDEVFS_ALLOW_SUSPEND ioctl.

Alan Stern

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-06 Thread Muni Sekhar
On Mon, May 6, 2024 at 7:59 PM Alan Stern  wrote:
>
> On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
> > Dear Linux USB Subsystem Community,
> >
> > I hope this email finds you well. We are currently working on a USB
> > device driver in the Linux kernel space, which supports the
> > suspend/resume functionality for a USB device using the struct
> > usb_driver's .suspend and .resume callbacks.
> >
> >
> > In our driver code, we perform a check to determine if the device has
> > remote wakeup capability. If the device supports remote wakeup, we
> > enable the device's autosuspend mode by setting the struct
> > usb_device->dev.power.autosuspend_delay parameter and then calling
> > usb_enable_autosuspend().
> >
> >
> > Similarly, to resume the suspended device, we expose an API to user
> > space via IOCTL. In this process, we set struct
> > usb_device->dev.power.autosuspend_delay to -1 and then call
> > usb_disable_autosuspend().
> >
> >
> > While we have successfully converted most of the USB device driver
> > functionality from kernel space to user space using libusb, we are now
> > seeking guidance on how to implement USB device suspend/resume in user
> > space. Specifically, we would like to know if libusb provides support
> > for achieving the suspend/resume functionality mentioned above.
> > Additionally, any insights or suggestions on how to accomplish this
> > task would be greatly appreciated.
>
> Your question is about libusb, right?  So you'll get better answers if
> you post it on the libusb mailing list rather than the linux-usb mailing
> list.
Can USB device suspend\resume  be implemented in user space driver
using software other than libusb?
If so, what are those methods or techniques to achieve USB device
suspend\resume , can you please provide clarity on this.
>
> Alan Stern
>
> > It's worth mentioning that our USB device driver also supports
> > Bulk\Coontrol I/O transfers and other functionalities.
> >
> >
> > Thank you in advance for any assistance you can provide. I look
> > forward to your valuable inputs and recommendations.
> >
> >
> > --
> > Thanks,
> > Sekhar
> >



-- 
Thanks,
Sekhar

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


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-06 Thread Muni Sekhar
On Mon, 6 May, 2024, 7:59 pm Alan Stern,  wrote:

> On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
> > Dear Linux USB Subsystem Community,
> >
> > I hope this email finds you well. We are currently working on a USB
> > device driver in the Linux kernel space, which supports the
> > suspend/resume functionality for a USB device using the struct
> > usb_driver's .suspend and .resume callbacks.
> >
> >
> > In our driver code, we perform a check to determine if the device has
> > remote wakeup capability. If the device supports remote wakeup, we
> > enable the device's autosuspend mode by setting the struct
> > usb_device->dev.power.autosuspend_delay parameter and then calling
> > usb_enable_autosuspend().
> >
> >
> > Similarly, to resume the suspended device, we expose an API to user
> > space via IOCTL. In this process, we set struct
> > usb_device->dev.power.autosuspend_delay to -1 and then call
> > usb_disable_autosuspend().
> >
> >
> > While we have successfully converted most of the USB device driver
> > functionality from kernel space to user space using libusb, we are now
> > seeking guidance on how to implement USB device suspend/resume in user
> > space. Specifically, we would like to know if libusb provides support
> > for achieving the suspend/resume functionality mentioned above.
> > Additionally, any insights or suggestions on how to accomplish this
> > task would be greatly appreciated.
>
> Your question is about libusb, right?  So you'll get better answers if
> you post it on the libusb mailing list rather than the linux-usb mailing
> list.
>
Can USB device suspend\resume be implemented in user space driver using
software other than libusb?

Alan Stern
>
> > It's worth mentioning that our USB device driver also supports
> > Bulk\Coontrol I/O transfers and other functionalities.
> >
> >
> > Thank you in advance for any assistance you can provide. I look
> > forward to your valuable inputs and recommendations.
> >
> >
> > --
> > Thanks,
> > Sekhar
> >
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver

2024-05-06 Thread Alan Stern
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
> Dear Linux USB Subsystem Community,
> 
> I hope this email finds you well. We are currently working on a USB
> device driver in the Linux kernel space, which supports the
> suspend/resume functionality for a USB device using the struct
> usb_driver's .suspend and .resume callbacks.
> 
> 
> In our driver code, we perform a check to determine if the device has
> remote wakeup capability. If the device supports remote wakeup, we
> enable the device's autosuspend mode by setting the struct
> usb_device->dev.power.autosuspend_delay parameter and then calling
> usb_enable_autosuspend().
> 
> 
> Similarly, to resume the suspended device, we expose an API to user
> space via IOCTL. In this process, we set struct
> usb_device->dev.power.autosuspend_delay to -1 and then call
> usb_disable_autosuspend().
> 
> 
> While we have successfully converted most of the USB device driver
> functionality from kernel space to user space using libusb, we are now
> seeking guidance on how to implement USB device suspend/resume in user
> space. Specifically, we would like to know if libusb provides support
> for achieving the suspend/resume functionality mentioned above.
> Additionally, any insights or suggestions on how to accomplish this
> task would be greatly appreciated.

Your question is about libusb, right?  So you'll get better answers if 
you post it on the libusb mailing list rather than the linux-usb mailing 
list.

Alan Stern

> It's worth mentioning that our USB device driver also supports
> Bulk\Coontrol I/O transfers and other functionalities.
> 
> 
> Thank you in advance for any assistance you can provide. I look
> forward to your valuable inputs and recommendations.
> 
> 
> -- 
> Thanks,
> Sekhar
> 

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


Re: ALSA: usb-audio: Adding mixer controls to Mbox3

2024-05-06 Thread Takashi Iwai
On Wed, 01 May 2024 16:31:35 +0200,
Manu wrote:
> 
> Thank you for all your help, Takashi!
> 
> I would like to add the hardware mixer controls for Mbox3.
> I have already identified every control in the function "mbox3_setup_defaults"
> of "quirks.c", but I am unsure about the structure needed to make the controls
> appear in alsamixer (further investigation is required). I would appreciate 
> any
> help you or anyone else can provide.

I believe it'd be helpful if you can show some mock up or any examples
you wanted to try (or had in your head).  If the question was about
the complexity or too many code to add there, you can split to another
file, too.


thanks,

Takashi

> 
> Manuel Barrio Linares
> 
> 
> On Wed, May 1, 2024 at 4:55 AM Takashi Iwai  wrote:
> >
> > On Tue, 30 Apr 2024 19:10:18 +0200,
> > Manuel Barrio Linares wrote:
> > >
> > > This adds support for all sample rates supported by the
> > > hardware,Digidesign Mbox 3 supports: {44100, 48000, 88200, 96000}
> > >
> > > Fixes syncing clock issues that presented as pops. To test this, without
> > > this patch playing 440hz tone produces pops.
> > >
> > > Clock is now synced between playback and capture interfaces so no more
> > > latency drift issue when using pipewire pro-profile.
> > > (https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3900)
> > >
> > > Signed-off-by: Manuel Barrio Linares 
> >
> > Applied to for-next branch now.  Thanks!
> >
> >
> > Takashi

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


Re: Adding a device support

2024-05-02 Thread Kwanghoon Son
> I have no idea (yet?) on how to do that,
> 
> I program a little, but not a driver/kernel coder at all ... .
> 
> This message is like a request where I could be involved ... .
Look at GitHub Issue 94. Already someone tried build in linux 6.2.

If you just want to use the driver, post an issue on GitHub or look at
it.

If you want to upstream your driver, read the Linux driver book first.

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


Re: Adding a device support

2024-05-02 Thread Rémi ESSAISSI

Le 02/05/2024 à 16:00, Greg KH a écrit :

On Thu, May 02, 2024 at 01:47:21PM +0200, Rémi ESSAISSI wrote:

Hello

I bought without checking its support a USB->VGA/HDMI adapter.

the Fresco Logic FL2000  .

Some code is at https://github.com/FrescoLogic/FL2000 .

But unfortunately unusable as is.


Why not?



There is no DRM support and not following the Kernel's "new" 
architecture, so since Linux 4.X or 5.X it barely compiles ... .






I would like to know if there is anything I can do to help getting it fully
supported .


Try forward-porting that driver and getting it to work?



I have no idea (yet?) on how to do that,

I program a little, but not a driver/kernel coder at all ... .


This message is like a request where I could be involved ... .


have fun!

greg k-h


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


Re: Adding a device support

2024-05-02 Thread Greg KH
On Thu, May 02, 2024 at 01:47:21PM +0200, Rémi ESSAISSI wrote:
> Hello
> 
> I bought without checking its support a USB->VGA/HDMI adapter.
> 
> the Fresco Logic FL2000  .
> 
> Some code is at https://github.com/FrescoLogic/FL2000 .
> 
> But unfortunately unusable as is.

Why not?

> I would like to know if there is anything I can do to help getting it fully
> supported .

Try forward-porting that driver and getting it to work?

have fun!

greg k-h

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


Re: Userspace or kernelspace driver once again

2024-04-26 Thread Tom Mitchell
You asked what it depends on.
On Sun, Apr 21, 2024 at 5:36 AM Patryk  wrote:
>
> Suppose that you want to use a driver that controls fans ,let's say
> max31785. You have two options to chose:
> - kernel space driver that is already available in mainline linux
> - userspace driver that comes from Hardware Abstraction Layer library
> that also has an implementation, the library is a primary hardware
> access library used by all our projects
>
> What would you choose? And why? And if "it depends..." then depends on
> what actually?

In this case the timing of the I2C/SMBUS lines  and the hardware you
interface wiht; to and from.
It is "rare" to have hardware specific to  I2C/SMBUS in the same way
that a UART or USB device controller
of a PC  does the details of "bit banging" against  strict timing
requirements that cannot be interrupted for the most part.
It gets interesting if the device is also bidirectional and can have
concurrent send and receive lines.

What host do you want to work on?

The resources of the host sets the stage.
This may cover a lot of what you need to know.
https://www.cast-inc.com/sites/default/files/pdfs/2023-06/cast_i2c-smbus-amd.pdf

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


Re: git send-email and gmail smtp

2024-04-17 Thread Konstantin Ryabitsev
On Wed, Apr 17, 2024 at 10:30:56AM -0600, jim.cro...@gmail.com wrote:
> so I tried to submit a patchset via sendemail,
> and ran aground on authorization.
> 
> its been a while since I sent from this computer,
> laptop power cord is cut :-(
> but failure wording is ambiguous
> 
> 5.7.8 Username and Password not accepted. For more information, go to
> 5.7.8  https://support.google.com/mail/?p=BadCredentials
> j15-20020a0566022ccf00b007d6905cc017sm3758492iow.4 - gsmtp
> 
> Essentially, google is changing policy,
> and 2FA is coming (or just arrived)
> 
> is there a well-travelled path to work around this issue?

You can still use app passwords with gmail, you just have to set 2FA on 
your account. There are guides on the net how to do that.

Alternatively, you can also use the web submission endpoint with b4 -- 
documentation is available here:

https://b4.docs.kernel.org/en/latest/contributor/overview.html

-K

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


Re: git send-email and gmail smtp

2024-04-17 Thread Siddh Raman Pant
On Wed, 17 Apr 2024 22:00:56 +0530, Jim Cromie wrote:
> so I tried to submit a patchset via sendemail,
> and ran aground on authorization.
> 
> its been a while since I sent from this computer,
> laptop power cord is cut :-(
> but failure wording is ambiguous
> 
> 5.7.8 Username and Password not accepted. For more information, go to
> 5.7.8  https://support.google.com/mail/?p=BadCredentials
> j15-20020a0566022ccf00b007d6905cc017sm3758492iow.4 - gsmtp
> 
> Essentially, google is changing policy,
> and 2FA is coming (or just arrived)
> 
> is there a well-travelled path to work around this issue?
> 
> something like ssh-key-agent ?

You can use app-passwords and store them in a keyring.

https://support.google.com/accounts/answer/185833?hl=en

Thanks,
Siddh

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


Re: git send-email and gmail smtp

2024-04-17 Thread Ezra Buehler
Hi,

> On 17 Apr 2024, at 18:34, jim.cro...@gmail.com wrote:
> 
> so I tried to submit a patchset via sendemail,
> and ran aground on authorization.
> 
> its been a while since I sent from this computer,
> laptop power cord is cut :-(
> but failure wording is ambiguous
> 
> 5.7.8 Username and Password not accepted. For more information, go to
> 5.7.8  https://support.google.com/mail/?p=BadCredentials
> j15-20020a0566022ccf00b007d6905cc017sm3758492iow.4 - gsmtp
> 
> Essentially, google is changing policy,
> and 2FA is coming (or just arrived)
> 
> is there a well-travelled path to work around this issue?

Maybe this site will be of help to you: https://git-send-email.io/

Cheers,
Ezra
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: uboot and kernel entry point, load address for booting kernel from FIT image

2024-04-12 Thread Richard

Hi,

System.map will not help you there, it is a map of all the Symbols (var 
and function names) inside the kernel, and mostly necesarry for debug 
output.


Ich think the load address you mean is dependent on your hardware and 
CPU, you should find it in board documentation. In general "Mastering 
Embedded Linux Programming" (forgot author but it's from Packt) is a 
good book on such things


-- Richard

On 12/04/2024 15:53, Lev Olshvang wrote:

Hi list,
uboot requires that  kernel entry point and  load address be specified 
at FIT spec

I thought this indo Should be sowewher in System.map
Can u help me how to find entry point in System.map or perhaps I 
vmllinux file?

ThanX

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


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


Re: Seeking help addressing maintainer objections

2024-04-03 Thread Bjørn Mork
Ian Pilcher  writes:

> It's not absolutely needed, but it does make it easier to unlink an LED
> from all devices by using the names of the symlinks in the LED's
> linked_devices directory, which will be kernel names.

Yes, I agree that things are much easier if those names can be fed
directly into the unlink attribute.  And even better if the names in the
linked_devices directory actually matched what you used to link them.

So why not go for "major:minor" everywhere?  I.e for link, unlink and
also for the symlinks in linked_devices.

>> And if file name with symlink resolution really is a problem, then why
>> can't you use the major:minor for link/unlink?  That's easy for
>> userspace to look up whether the input is a device path or a sysfs path.
>> And it avoids having to wait for an unrelated and unnecessary device
>> path creation.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248
>
> Personally, I don't think that using file paths is a problem, and it
> can be useful.  ("/dev/vg_root/lv_root" is probably more useful than
> "dm-0".)  OTOH, "sda" is slightly simpler than "/dev/sda", so I think
> that the ideal situation would be to have both interfaces available.
>
> I did propose using device numbers.  I never received a response from
> the maintainer.

I believe that's how most maintainers work unless the proposal was in
patch form :-)



Bjørn

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


Re: Seeking help addressing maintainer objections

2024-04-03 Thread Ian Pilcher

On 4/3/24 06:38, Bjørn Mork wrote:

Ian Pilcher  writes:


The maintainer of the LEDs subsystem considers this interface to be
"crazy", but he has not suggested any alternative.[3]


I read a strong suggestion that one of the unlink interfaces is
dropped.

You should probably read "crazy" as "unjustified".


(I have not been able to find any existing example of configuring
many-to-many relationships via sysfs.)


There's at least one such example, hidden under drivers/usb:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c

See the initial commit for justification and some of the background for
the choices made:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248


Thanks! Will take a look at that.


The second problem is the use of device file paths (including symbolic
link resolution), rather than kernel names, when creating associations.
This limitation exists because the block subsystem does not provide an
API to open a block device by its kernel name; only device file paths
and device numbers (major & minor) are supported.


So this explains why you can't have link_dev_by_path.  It still does not
explain why you need unlink_dev_by_name.


It's not absolutely needed, but it does make it easier to unlink an LED
from all devices by using the names of the symlinks in the LED's
linked_devices directory, which will be kernel names.


And if file name with symlink resolution really is a problem, then why
can't you use the major:minor for link/unlink?  That's easy for
userspace to look up whether the input is a device path or a sysfs path.
And it avoids having to wait for an unrelated and unnecessary device
path creation.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248


Personally, I don't think that using file paths is a problem, and it
can be useful.  ("/dev/vg_root/lv_root" is probably more useful than
"dm-0".)  OTOH, "sda" is slightly simpler than "/dev/sda", so I think
that the ideal situation would be to have both interfaces available.

I did propose using device numbers.  I never received a response from
the maintainer.

Thanks for taking the time to respond to this!

--

If your user interface is intuitive in retrospect ... it isn't intuitive



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


Re: Seeking help addressing maintainer objections

2024-04-03 Thread Bjørn Mork
Ian Pilcher  writes:

> The maintainer of the LEDs subsystem considers this interface to be
> "crazy", but he has not suggested any alternative.[3] 

I read a strong suggestion that one of the unlink interfaces is
dropped.

You should probably read "crazy" as "unjustified".

> (I have not been able to find any existing example of configuring
> many-to-many relationships via sysfs.)

There's at least one such example, hidden under drivers/usb:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c

See the initial commit for justification and some of the background for
the choices made:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248


> The second problem is the use of device file paths (including symbolic
> link resolution), rather than kernel names, when creating associations.
> This limitation exists because the block subsystem does not provide an
> API to open a block device by its kernel name; only device file paths
> and device numbers (major & minor) are supported.

So this explains why you can't have link_dev_by_path.  It still does not
explain why you need unlink_dev_by_name.

And if file name with symlink resolution really is a problem, then why
can't you use the major:minor for link/unlink?  That's easy for
userspace to look up whether the input is a device path or a sysfs path.
And it avoids having to wait for an unrelated and unnecessary device
path creation.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/ledtrig-usbport.c

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/ledtrig-usbport.c?id=0f247626cbbfa2010d2b86fdee652605e084e248

Bjørn

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


Re: Coding style when using atomic_dec_and_test

2024-03-30 Thread Valdis Klētnieks
On Sat, 30 Mar 2024 21:52:29 -0300, Camila Alvarez Inostroza said:

> I've seen two ways of handling the resulting operation, below are a couple
> of examples:
> (1) if (!atomic_dec_and_test(&rd->refcount))
>return;
>   call_rcu(&rd->rcu, free_rootdomain);
>
> (2)  if (atomic64_dec_and_test(&map->refcnt)) {
>/* bpf_map_free_id() must be called first */
>...
> }
>
> Is it prefered to use one option over the other? Or is it just personal
> preference?

Yes. :)

Basically, it will depend on what the code logic structure is like.  If the 
logical
way to do it is "if it fails, return now", then you do (1).  If the logical 
structure
is "if it succeeds, do this before continuing", you do (2).  In other cases,
you may want to do the "structured goto" the kernel uses to unwind allocations
and locks that happened before the failure.

The above is not an exhaustive list.


pgpfYKDtBDdNk.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Controlling the same I2C device from user and kernel space

2024-03-26 Thread Patryk
Hi again, a small correction
> part) using spidev driver and still be able to develop a kernel driver
Of course, I meant i2c-dev, not spidev...

Best regards
Patryk

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


Re: Seeking Suggestions for Open Source Projects to Contribute to as a New Contributor

2024-03-11 Thread Pragati Ghatte
Hi Ayan,

Thanks a lot for your guidance and the links! I'll check out the Xen
project and dive into those beginner-friendly tasks. Your support means a
lot!
Best regards,
Pragati

On Mon, 11 Mar 2024 at 19:19, AYAN KUMAR HALDER 
wrote:

> Hi Pragati,
>
> Glad to hear your interest.
>
> If working in hypervisors excite you, then you can have a look at Xen
> project "https://xenproject.org";.
> You would need to subscribe to the xen-devel mailing list.
>
> There are some things which a newbie can get started with. For eg
>
> https://lore.kernel.org/all/alpine.DEB.2.22.394.2309281609360.1996340@ubuntu-linux-20-04-desktop/T/#m0971ebab276a4f7e63982523cf535059322a4f2e
>
> https://gitlab.com/groups/xen-project/-/issues/?label_name%5B%5D=Difficulty%3A%3A1-GOOD%20FIRST%20ISSUE
>
> 
>
> https://gitlab.com/groups/xen-project/-/issues/?label_name%5B%5D=Difficulty%3A%3A1-EASY
>
> 
>
> You can join the matrix and ask for more suggestions/details.
>
> Kind regards,
> Ayan
>
>
>
>
> On Mon, Mar 11, 2024 at 1:29 PM Pragati Ghatte 
> wrote:
>
>> I hope this message finds you well. I am eager to dive into the world of
>> open source contributions and am seeking guidance on suitable projects to
>> begin my journey. As a new contributor, I am looking for projects that are
>> welcoming to beginners and offer opportunities to learn and grow within the
>> kernel development space.
>>
>> I would greatly appreciate any recommendations or suggestions for open
>> source projects within the kernel ecosystem that are beginner-friendly and
>> actively seeking contributions. Whether it's documentation improvements,
>> bug fixes, or small feature additions, I am enthusiastic about contributing
>> in any way I can.
>>
>> Thank you in advance for your assistance and support. I am looking
>> forward to becoming an active member of the community and contributing to
>> the advancement of open source software.
>>
>> Best regards,
>> Pragati ghatte
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Which tree to track: linux-next or staging?

2024-03-11 Thread Jonathan Bergh
On Mon, Mar 11, 2024 at 09:56:06AM -0400, Konstantin Ryabitsev wrote:
> On Sat, Mar 09, 2024 at 03:49:15PM +0100, Jonathan Bergh wrote:
> > I have had the opportunity to submit a few patches, which has been
> > really fun. However, a while back i submitted patches for fixes that i
> > realised after had already been patched in GregKH tree ... and i
> > realised i had been developing against Linus's master branch, and not
> > linux-next.
> > 
> > But my question is, is it better to develop against linux-next or in
> > newbies cases, one of GregKH's (staging) branches? Maybe
> > staging/master or staging/staging-next?
> 
> There is no hard and fast rule about it, but in general:
> 
> - if you are closely working with a particular subsystem, the best course of
>   action is to develop against the indicated tree/branch (e.g. see T: entries
>   in the MAINTAINERS file); you should rebase your series to the latest before
>   sending it off to the maintainer
> - if you are an occasional contributor, you should use either the latest next
>   tag for submitting your patches, or the latest mainline tag
> - if you are sending a one-off patch, basing it off of the latest mainline tag
>   is just fine

Got it, thanks for that, good advice. 
 
> With any of these approaches you *will* occasionally have a mid-air collision
> with someone else -- it's just a reality when it comes to distributed
> workflows.
> 
> -K

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


Re: Which tree to track: linux-next or staging?

2024-03-11 Thread Konstantin Ryabitsev
On Sat, Mar 09, 2024 at 03:49:15PM +0100, Jonathan Bergh wrote:
> I have had the opportunity to submit a few patches, which has been
> really fun. However, a while back i submitted patches for fixes that i
> realised after had already been patched in GregKH tree ... and i
> realised i had been developing against Linus's master branch, and not
> linux-next.
> 
> But my question is, is it better to develop against linux-next or in
> newbies cases, one of GregKH's (staging) branches? Maybe
> staging/master or staging/staging-next?

There is no hard and fast rule about it, but in general:

- if you are closely working with a particular subsystem, the best course of
  action is to develop against the indicated tree/branch (e.g. see T: entries
  in the MAINTAINERS file); you should rebase your series to the latest before
  sending it off to the maintainer
- if you are an occasional contributor, you should use either the latest next
  tag for submitting your patches, or the latest mainline tag
- if you are sending a one-off patch, basing it off of the latest mainline tag
  is just fine

With any of these approaches you *will* occasionally have a mid-air collision
with someone else -- it's just a reality when it comes to distributed
workflows.

-K

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


Re: Seeking Suggestions for Open Source Projects to Contribute to as a New Contributor

2024-03-11 Thread AYAN KUMAR HALDER
Hi Pragati,

Glad to hear your interest.

If working in hypervisors excite you, then you can have a look at Xen
project "https://xenproject.org";.
You would need to subscribe to the xen-devel mailing list.

There are some things which a newbie can get started with. For eg
https://lore.kernel.org/all/alpine.DEB.2.22.394.2309281609360.1996340@ubuntu-linux-20-04-desktop/T/#m0971ebab276a4f7e63982523cf535059322a4f2e
https://gitlab.com/groups/xen-project/-/issues/?label_name%5B%5D=Difficulty%3A%3A1-GOOD%20FIRST%20ISSUE

https://gitlab.com/groups/xen-project/-/issues/?label_name%5B%5D=Difficulty%3A%3A1-EASY


You can join the matrix and ask for more suggestions/details.

Kind regards,
Ayan




On Mon, Mar 11, 2024 at 1:29 PM Pragati Ghatte 
wrote:

> I hope this message finds you well. I am eager to dive into the world of
> open source contributions and am seeking guidance on suitable projects to
> begin my journey. As a new contributor, I am looking for projects that are
> welcoming to beginners and offer opportunities to learn and grow within the
> kernel development space.
>
> I would greatly appreciate any recommendations or suggestions for open
> source projects within the kernel ecosystem that are beginner-friendly and
> actively seeking contributions. Whether it's documentation improvements,
> bug fixes, or small feature additions, I am enthusiastic about contributing
> in any way I can.
>
> Thank you in advance for your assistance and support. I am looking forward
> to becoming an active member of the community and contributing to the
> advancement of open source software.
>
> Best regards,
> Pragati ghatte
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Kernelnewbies

2024-03-01 Thread Turritopsis Dohrnii Teo En Ming
On Thursday, February 8th, 2024 at 11:32 PM, Greg KH  wrote:

> On Thu, Feb 08, 2024 at 03:11:33PM +, Turritopsis Dohrnii Teo En Ming 
> wrote:
> 
> > Subject: Kernelnewbies
> > 
> > Good day from Singapore,
> > 
> > If we want to do kernel coding, what is the programming language that we 
> > must know?
> 
> 
> Take a look at the Linux kernel source code itself to see what is
> needed, it all depends on what portion(s) you are modifying.
> 
> good luck!
> 
> greg k-h

Noted with thanks, Greg!

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: PHY drivers

2024-02-28 Thread achraf boussetta
Yes, a generic software reads at first the ID of the Phy using MDIO and
then if an ID has matched specific functions will be called.

Take a look at the realtek file for your reference:
https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/realtek.c#L882


On Wed, 28 Feb 2024 at 15:49, Patryk  wrote:

> Hi, I've got a question regarding phy drivers. Supposed that I want to use
> an ethernet phy device -  in general - do I need a specific driver to
> handle this, or is it handled by some generic eth phy layer that can
> configure (through MDIO) and exchange data (through XMII) in a generic,
> vendor-agnostic way?
>
> Best regards
> Patryk
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Before submitting a driver for Casper Excalibur Laptops

2024-02-21 Thread Greg KH
On Wed, Feb 21, 2024 at 01:30:11AM +0300, Mustafa Ekşi wrote:
> 2. Where should I put my driver?
> staging/ or platform/x86/? I'm planning to extend my driver to support more
> laptops from the same vendor.

drivers/staging/ is only for code that is not ready to be merged and it
must have a TODO file that lists what needs to be done.  I'd recommend
just fixing the issues first and submitting it for drivers/platform/
directly.

> 3. Should I wait to extend support of the driver before submitting it?

No, send it now, no need to wait!

good luck!

greg k-h

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


Re: firefox does not start with 6.8-rc

2024-02-11 Thread Greg KH
On Sat, Feb 10, 2024 at 11:41:27AM +0100, Philipp Hortmann wrote:
> Hi,
> 
> compiled the latest staging kernel on my xubuntu laptop. It starts fine but
> I cannot start my firefox anymore. This happens only with kernel 6.8-rcx.
> With kernel 6.7 no issue at all. Find logs below. Found in some forum that
> it is fixed in some later rc on an other tree. Tried to find this patch
> series that fixes this. But was not able to.
> 
> But anyway is this a kernel issue? Do the kernel developers care?

Yes, but this looks like a self-inflicted issue:

> mr0@mr0-dell:~$ sudo dmesg -c
> [  281.781051] audit: type=1400 audit(1707558512.842:62): apparmor="DENIED"
> operation="capable" class="cap"
> profile="/snap/snapd/20671/usr/lib/snapd/snap-confine" pid=1566
> comm="snap-confine" capability=12  capname="net_admin"

apparmor is saying no here.  Perhaps you need to update your rules for
it?

thanks,

greg k-h

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


Re: Boot log before panic

2024-02-09 Thread Mandeep Sandhu
How you access the log depends on the Linux distribution you're using
(whether its systemd based or not).

If you have journalctl, you can get the last boot log with

$ journalctl -k -b 1
(-k is to get get dmesg logs)

HTH,
-mandeep

On Fri, Feb 9, 2024 at 2:12 PM Abdulrasaq Lawani
 wrote:
>
> Hi all,
>
> Please, how do I locate the logs for a system boot that had a kernel panic 
> before booting was completed?
>
> Best regards,
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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


Re: Kernelnewbies

2024-02-08 Thread Greg KH
On Thu, Feb 08, 2024 at 03:11:33PM +, Turritopsis Dohrnii Teo En Ming wrote:
> Subject: Kernelnewbies
> 
> Good day from Singapore,
> 
> If we want to do kernel coding, what is the programming language that we must 
> know?

Take a look at the Linux kernel source code itself to see what is
needed, it all depends on what portion(s) you are modifying.

good luck!

greg k-h

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


Re: Generic USB LED HID driver

2024-01-19 Thread Kirill Yatsenko
> > Hello Greg,
> >
> > Thanks for the suggestions!
> > Yes, it will be better to implement the communication from the
userspace.
> >
> > However, I was curious if the kernel implements some generic LED HID
> > interface already,
> > without the need to write custom code. Similarly, as it's done for
example
> > for the HID multitouch,
> > where the device only needs to report the correct report descriptor.

> I do not think there is a generic HID description yet, is there?  If so,
> the kernel should support it, otherwise it is all vendor-specific stuff
> that belongs in userspace.

Thanks again for your answer.
There is "LED Page" defined in HID Usage Tables. However, I can't find any
drivers that implement it.

But maybe I'm looking in the wrong direction.

Best regards,
Kirill Yatsenko



On Fri, 19 Jan 2024 at 13:07, Greg KH  wrote:

> On Fri, Jan 19, 2024 at 12:45:52PM +0100, Kirill Yatsenko wrote:
> > Hello Greg,
> >
> > Thanks for the suggestions!
> > Yes, it will be better to implement the communication from the userspace.
> >
> > However, I was curious if the kernel implements some generic LED HID
> > interface already,
> > without the need to write custom code. Similarly, as it's done for
> example
> > for the HID multitouch,
> > where the device only needs to report the correct report descriptor.
>
> I do not think there is a generic HID description yet, is there?  If so,
> the kernel should support it, otherwise it is all vendor-specific stuff
> that belongs in userspace.
>
> thanks,
>
> greg k-h
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Generic USB LED HID driver

2024-01-19 Thread Greg KH
On Fri, Jan 19, 2024 at 12:45:52PM +0100, Kirill Yatsenko wrote:
> Hello Greg,
> 
> Thanks for the suggestions!
> Yes, it will be better to implement the communication from the userspace.
> 
> However, I was curious if the kernel implements some generic LED HID
> interface already,
> without the need to write custom code. Similarly, as it's done for example
> for the HID multitouch,
> where the device only needs to report the correct report descriptor.

I do not think there is a generic HID description yet, is there?  If so,
the kernel should support it, otherwise it is all vendor-specific stuff
that belongs in userspace.

thanks,

greg k-h

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


Re: Generic USB LED HID driver

2024-01-19 Thread Kirill Yatsenko
Hello Greg,

Thanks for the suggestions!
Yes, it will be better to implement the communication from the userspace.

However, I was curious if the kernel implements some generic LED HID
interface already,
without the need to write custom code. Similarly, as it's done for example
for the HID multitouch,
where the device only needs to report the correct report descriptor.

Best regards,
Kirill Yatsenko

On Fri, 19 Jan 2024 at 12:17, Greg KH  wrote:

> On Fri, Jan 19, 2024 at 11:21:51AM +0100, Kirill Yatsenko wrote:
> > Hello,
> >
> > I'm trying to find the Linux kernel driver in the tree that implements
> the
> > HID LED usage table.
> > The only driver that I've found is the hid-led.c. However, it seems to
> > support only specific devices.
> >
> > The device with which I'm trying to interface is the custom-made board
> with
> > atxmega and some LEDS connected to it.
> > Currently, the communication is done through the vendor-specific HID
> > protocol.
> > The custom USB HID kernel module is implemented to communicate with the
> > device.
>
> Why not do this from userspace using libusb or the generic hid userspace
> api?  Why do you need a kernel driver?
>
> thanks,
>
> greg k-h
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Generic USB LED HID driver

2024-01-19 Thread Greg KH
On Fri, Jan 19, 2024 at 11:21:51AM +0100, Kirill Yatsenko wrote:
> Hello,
> 
> I'm trying to find the Linux kernel driver in the tree that implements the
> HID LED usage table.
> The only driver that I've found is the hid-led.c. However, it seems to
> support only specific devices.
> 
> The device with which I'm trying to interface is the custom-made board with
> atxmega and some LEDS connected to it.
> Currently, the communication is done through the vendor-specific HID
> protocol.
> The custom USB HID kernel module is implemented to communicate with the
> device.

Why not do this from userspace using libusb or the generic hid userspace
api?  Why do you need a kernel driver?

thanks,

greg k-h

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


Re: Boot stucks at "Loading initial ramdisk"

2024-01-05 Thread Dileep Sankhla
On Fri, Jan 5, 2024 at 3:02 PM Valdis Klētnieks  wrote:
> 'make localmodconfig' is your friend.
>
> Make sure to plug in all your various USB or bluetooth  etc devices first,
> so their driver modules get loaded.

Yeah, I've begun using it too.

Regards,
Dileep

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


Re: Boot stucks at "Loading initial ramdisk"

2024-01-05 Thread Aditya Gupta

On 05/01/24 15:02, Valdis Klētnieks wrote:


On Fri, 05 Jan 2024 10:42:53 +0530, Aditya Gupta said:


It's a good start to use the distro config for building a kernel.
PS. I have been able to successfully boot by building with defconfig, then
manually enabling some drivers according to error messages during boot,

'make localmodconfig' is your friend.

Make sure to plug in all your various USB or bluetooth  etc devices first,
so their driver modules get loaded.


Yes, I use it. Thanks for suggesting that Valdis.

Thanks,
Aditya Gupta


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


Re: Boot stucks at "Loading initial ramdisk"

2024-01-05 Thread Valdis Klētnieks
On Fri, 05 Jan 2024 10:42:53 +0530, Aditya Gupta said:

> It's a good start to use the distro config for building a kernel.

> PS. I have been able to successfully boot by building with defconfig, then
> manually enabling some drivers according to error messages during boot,

'make localmodconfig' is your friend.

Make sure to plug in all your various USB or bluetooth  etc devices first,
so their driver modules get loaded.


pgpXTxl9lAI03.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Re: Boot stucks at "Loading initial ramdisk"

2024-01-05 Thread Dileep Sankhla
Hi Aditya,

Yes, I also meant the same.

Thanks for the additional info though.

Regards,
Dileep

On Fri, Jan 5, 2024 at 1:33 PM Aditya Gupta  wrote:
>
> Hi Dileep,
>
> On Mon, Jan 01, 2024 at 04:46:03PM +0530, Dileep Sankhla wrote:
> > >
> > > Thanks for your solution. Mine is fine in size and I am already using
> > > MODULES=dep.
> > >
> >
> > Sorry, my bad. I thought 18M was good enough but after asking this on
> > LinuxQuestions.org, I got to know that it was not sufficient for the boot
> > success (see [1]). Copying the existing kernel version's config from
> > `/boot` and running `make olddefconfig` solved the size issue for me. It is
> > now ~78M. The size of the kernel's initrd that I was using earlier is ~71M.
> >
>
> Just for the clarity, the size of initrd being only 18 MB is likely not
> the root cause for your system not booting, it would likely be that some
> modules were missing earlier.
>
> Likely why you built linux with a default config (defconfig), many
> modules might have been missing, which are required on your system to
> boot correctly. For example, file system support for btrfs will require
> the btrfs module, etc.
>
> Generally while creating initrd, `dracut` (on rhel/fedora), or
> `mkinitcpio`/`mkinitramfs` also copy your kernel's modules (at
> /lib/modules/new-kernel-version/*) to the initrd.
>
> Since you had less modules the first time you built with defconfig, so
> initrd also had less modules, and hence size was only 18MB.
>
> Later when you built using the distro kernel's config, you likely had
> many more modules, and hence more modules were put in the initrd also,
> causing it's size to increase, and since you used distro kernel config,
> so your modules would be similar in the kernel you built, and hence
> similar size of the initrd ~70MB.
>
> It's a good start to use the distro config for building a kernel.
>
> PS. I have been able to successfully boot by building with defconfig,
> then manually enabling some drivers according to error messages during
> boot, but that is for learning only, normally it might be a waste of
> time.
> And also I boot my ArchLinux with no initrd, and have had even smaller
> initrd and booted successfully, how I did that was building only the
> modules I knew my system needed as built-in.
>
> Regards,
> Aditya Gupta
>

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


Re: Re: Boot stucks at "Loading initial ramdisk"

2024-01-05 Thread Aditya Gupta
Hi Dileep,

On Mon, Jan 01, 2024 at 04:46:03PM +0530, Dileep Sankhla wrote:
> >
> > Thanks for your solution. Mine is fine in size and I am already using
> > MODULES=dep.
> >
> 
> Sorry, my bad. I thought 18M was good enough but after asking this on
> LinuxQuestions.org, I got to know that it was not sufficient for the boot
> success (see [1]). Copying the existing kernel version's config from
> `/boot` and running `make olddefconfig` solved the size issue for me. It is
> now ~78M. The size of the kernel's initrd that I was using earlier is ~71M.
> 

Just for the clarity, the size of initrd being only 18 MB is likely not
the root cause for your system not booting, it would likely be that some
modules were missing earlier.

Likely why you built linux with a default config (defconfig), many
modules might have been missing, which are required on your system to
boot correctly. For example, file system support for btrfs will require
the btrfs module, etc.

Generally while creating initrd, `dracut` (on rhel/fedora), or
`mkinitcpio`/`mkinitramfs` also copy your kernel's modules (at
/lib/modules/new-kernel-version/*) to the initrd.

Since you had less modules the first time you built with defconfig, so
initrd also had less modules, and hence size was only 18MB.

Later when you built using the distro kernel's config, you likely had
many more modules, and hence more modules were put in the initrd also,
causing it's size to increase, and since you used distro kernel config,
so your modules would be similar in the kernel you built, and hence
similar size of the initrd ~70MB.

It's a good start to use the distro config for building a kernel.

PS. I have been able to successfully boot by building with defconfig,
then manually enabling some drivers according to error messages during
boot, but that is for learning only, normally it might be a waste of
time.
And also I boot my ArchLinux with no initrd, and have had even smaller
initrd and booted successfully, how I did that was building only the
modules I knew my system needed as built-in.

Regards,
Aditya Gupta


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


Re: Identifying the initial bug within the x86 architecture subsystem

2024-01-03 Thread Dileep Sankhla
On Wed, Jan 3, 2024 at 3:28 PM Greg KH  wrote:
> And maybe there are no x86-specific bugs at the moment?

Yes, I think so.

>Try running linux-next and see if you have any issues with any subsystem, if 
>so, try
> working on that.

 Sure, I will try it next.

Regards,
Dileep

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


Re: Identifying the initial bug within the x86 architecture subsystem

2024-01-03 Thread Greg KH
On Wed, Jan 03, 2024 at 03:23:13PM +0530, Dileep Sankhla wrote:
> On Wed, Jan 3, 2024 at 12:33 PM Greg KH  wrote:
> > What do you mean by "first bug"?  Why does the location in an
> > arbitrary list matter?
> 
> Hello Greg,
> 
> >From "first bug" I meant the initial bug for me to solve under this 
> >subsystem.
> 
> > Also, bugzilla is not used by many kernel subsystems, so perhaps the
> > items there just aren't relevant for this one either?
> 
> I looked for the bugs in the subsystem's mailing list but did not find
> anything beginning with the subject line "PROBLEM: ".

I have never seen a bug report for the kernel come in with that in the
subject line, sorry.  So that would be one reason why you might not find
anything.

And maybe there are no x86-specific bugs at the moment?  Try running
linux-next and see if you have any issues with any subsystem, if so, try
working on that.

good luck!

greg k-h

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


Re: Identifying the initial bug within the x86 architecture subsystem

2024-01-03 Thread Dileep Sankhla
On Wed, Jan 3, 2024 at 12:33 PM Greg KH  wrote:
> What do you mean by "first bug"?  Why does the location in an
> arbitrary list matter?

Hello Greg,

From "first bug" I meant the initial bug for me to solve under this subsystem.

> Also, bugzilla is not used by many kernel subsystems, so perhaps the
> items there just aren't relevant for this one either?

I looked for the bugs in the subsystem's mailing list but did not find
anything beginning with the subject line "PROBLEM: ".

Following is the query I used in the lkml's archive mirror (see [1]):

subsystem: x86 architecture (32-bit and 64-bit)

query: s:"PROBLEM: " + t:t...@linutronix.de + t:mi...@redhat.com +
t:b...@alien8.de + t:dave.han...@linux.intel.com + t:x...@kernel.org +
c:linux-ker...@vger.kernel.org

Regards,
Dileep

[1]: https://lore.kernel.org/lkml/

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


Re: Identifying the initial bug within the x86 architecture subsystem

2024-01-02 Thread Greg KH
On Wed, Jan 03, 2024 at 11:12:57AM +0530, Dileep Sankhla wrote:
> Last night, I dedicated time to go through bugs on Bugzilla (see [1]),
> considering their priorities but I could not figure out which one to
> pick. While I found only a couple of bugs with the latest modification
> date, I lack the same hardware as the original poster (OP) to
> reproduce and fix those bugs. How can I identify the first bug in this
> subsystem? Given the relatively low number of bugs, should I consider
> reaching out to the maintainer of `arch/x86/boot` if I cannot find a
> suitable one to fix?

What do you mean by "first bug"?  Why does the location in an
arbitrary list matter?

Also, bugzilla is not used by many kernel subsystems, so perhaps the
items there just aren't relevant for this one either?

good luck!

greg k-h

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


Re: Boot stucks at "Loading initial ramdisk"

2024-01-01 Thread Dileep Sankhla
On Fri, Dec 22, 2023 at 5:07 PM Dileep Sankhla 
wrote:

> Hi Soumya,
>
> On Fri, Dec 22, 2023 at 2:24 PM Soumya Negi 
> wrote:
>
>> Hi Dileep,
>>
>> On Thu, Dec 21, 2023 at 05:58:23PM +0530, Dileep Sankhla wrote:
>> > Hello,
>> >
>> > I have cloned and built the latest rc kernel using the default config
>> but
>> > on boot, it stucks at "Loading initial ramdisk". I have tried booting
>> after
>> > removing the "quiet" option from the kernel parameters just before
>> > selecting the kernel from the grub menu. I have also tried adding
>> > "dis_ucode_ldr" parameter to the initial parameters but all in vain.
>> >
>> > How to look for the underlying issue and solve it?
>> >
>> > Regards,
>> > Dileep
>>
>> I had this issue as well. I found a solution on stackexchange(..I think)
>> that I wanted to link here.. but can't seem to find it now. For
>> reference, I
>> was using Ubuntu. This was my case:
>>
>> * Possible reason - initrd.img file is too large
>> I checked the size of initrd.img- at /boot. The file was
>> ~500mb,
>> much larger than the initrd for the kernel that came with Ubuntu(~40mb)
>>
>> * Possible solution -
>> Before installing the kernel, change  MODULES=most to MODULES=dep  in
>> /etc/initramfs-tools/initramfs.conf to generate smaller initrd.img files.
>> The new initrd's for all other kernels I have installed afterwards have
>> been
>> ~55MB.
>>
>
> Thanks for your solution. Mine is fine in size and I am already using
> MODULES=dep.
>

Sorry, my bad. I thought 18M was good enough but after asking this on
LinuxQuestions.org, I got to know that it was not sufficient for the boot
success (see [1]). Copying the existing kernel version's config from
`/boot` and running `make olddefconfig` solved the size issue for me. It is
now ~78M. The size of the kernel's initrd that I was using earlier is ~71M.


>> Regards,
>> Soumya Negi
>
>
> Regards,
> Dileep.
>


Regards,
Dileep

[1]:
https://www.linuxquestions.org/questions/linux-newbie-8/boot-freezes-at-loading-initial-ramdisk-4175732025/#post6472047
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Boot stucks at "Loading initial ramdisk"

2023-12-22 Thread Dileep Sankhla
Hi Soumya,

On Fri, Dec 22, 2023 at 2:24 PM Soumya Negi  wrote:

> Hi Dileep,
>
> On Thu, Dec 21, 2023 at 05:58:23PM +0530, Dileep Sankhla wrote:
> > Hello,
> >
> > I have cloned and built the latest rc kernel using the default config but
> > on boot, it stucks at "Loading initial ramdisk". I have tried booting
> after
> > removing the "quiet" option from the kernel parameters just before
> > selecting the kernel from the grub menu. I have also tried adding
> > "dis_ucode_ldr" parameter to the initial parameters but all in vain.
> >
> > How to look for the underlying issue and solve it?
> >
> > Regards,
> > Dileep
>
> I had this issue as well. I found a solution on stackexchange(..I think)
> that I wanted to link here.. but can't seem to find it now. For reference,
> I
> was using Ubuntu. This was my case:
>
> * Possible reason - initrd.img file is too large
> I checked the size of initrd.img- at /boot. The file was
> ~500mb,
> much larger than the initrd for the kernel that came with Ubuntu(~40mb)
>
> * Possible solution -
> Before installing the kernel, change  MODULES=most to MODULES=dep  in
> /etc/initramfs-tools/initramfs.conf to generate smaller initrd.img files.
> The new initrd's for all other kernels I have installed afterwards have
> been
> ~55MB.
>

Thanks for your solution. Mine is fine in size and I am already using
MODULES=dep.


> Regards,
> Soumya Negi


Regards,
Dileep.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Boot stucks at "Loading initial ramdisk"

2023-12-22 Thread Dileep Sankhla
Hi Bagas,

On Fri, Dec 22, 2023 at 12:24 PM Bagas Sanjaya  wrote:

> On Thu, Dec 21, 2023 at 05:58:23PM +0530, Dileep Sankhla wrote:
> > Hello,
> >
> > I have cloned and built the latest rc kernel using the default config but
> > on boot, it stucks at "Loading initial ramdisk". I have tried booting
> after
> > removing the "quiet" option from the kernel parameters just before
> > selecting the kernel from the grub menu. I have also tried adding
> > "dis_ucode_ldr" parameter to the initial parameters but all in vain.
> >
>
> For initramfs, make sure to follow instructions specific to your distro
> (search the web if you're unsure). For example, as I'm on Arch, I use
> mkinitcpio (see [1]) to generate initramfs after compiling the kernel.
>
>
On "sudo make install", I get an output line as "update-initramfs:
Generating /boot/initrd.img-6.7.0-rc6-test". I have not gone through
Makefile though. So I think I am using the right tool on my distro (Ubuntu
22.04.03 LTS).
As you suggested, I also manually deleted and created the image using
update-initramfs (see [1]) after compiling the kernel. Still the same
problem.


> Thanks.
>
> [1]: https://wiki.archlinux.org/title/Mkinitcpio
>
> --
> An old man doll... just what I always wanted! - Clara
>

Regards,
Dileep.

[1]:
https://manpages.ubuntu.com/manpages/jammy/en/man8/update-initramfs.8.html

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


Re: Boot stucks at "Loading initial ramdisk"

2023-12-22 Thread Dileep Sankhla
Hi Valdis,

On Fri, Dec 22, 2023 at 10:52 AM Valdis Klētnieks 
wrote:

> On Thu, 21 Dec 2023 17:58:23 +0530, Dileep Sankhla said:
>
> > I have cloned and built the latest rc kernel using the default config but
> > on boot, it stucks at "Loading initial ramdisk". I have tried booting
> after
> > removing the "quiet" option from the kernel parameters just before
> > selecting the kernel from the grub menu.
>
> So when you remove 'quiet', what's the last output you get from the kernel?
>

I see no output from the kernel.


> You might also take a look at whether the initramfs image was installed to
> the right
> location, and whether its size/contents seem reasonable.
>
After checking the GRUB config (/boot/grub/grub.cfg) for both bootable and
non-bootable kernels, I can confirm that the initramfs image was installed
to the right location. Its size is only 18M. The bootable kernel release's
initramfs image is 71M in size.

I find similar contents in both of them though. Here is the contents
of initrd.img-6.7.0-rc6-test (see [1]).

Regards,
Dileep.

[1]: https://pastebin.com/1cDZDvj8
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Boot stucks at "Loading initial ramdisk"

2023-12-22 Thread Soumya Negi
Hi Dileep,

On Thu, Dec 21, 2023 at 05:58:23PM +0530, Dileep Sankhla wrote:
> Hello,
> 
> I have cloned and built the latest rc kernel using the default config but
> on boot, it stucks at "Loading initial ramdisk". I have tried booting after
> removing the "quiet" option from the kernel parameters just before
> selecting the kernel from the grub menu. I have also tried adding
> "dis_ucode_ldr" parameter to the initial parameters but all in vain.
> 
> How to look for the underlying issue and solve it?
> 
> Regards,
> Dileep

I had this issue as well. I found a solution on stackexchange(..I think)
that I wanted to link here.. but can't seem to find it now. For reference, I
was using Ubuntu. This was my case:

* Possible reason - initrd.img file is too large
I checked the size of initrd.img- at /boot. The file was ~500mb,
much larger than the initrd for the kernel that came with Ubuntu(~40mb)

* Possible solution - 
Before installing the kernel, change  MODULES=most to MODULES=dep  in 
/etc/initramfs-tools/initramfs.conf to generate smaller initrd.img files.
The new initrd's for all other kernels I have installed afterwards have been
~55MB.

Regards,
Soumya Negi

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


Re: Boot stucks at "Loading initial ramdisk"

2023-12-21 Thread Bagas Sanjaya
On Thu, Dec 21, 2023 at 05:58:23PM +0530, Dileep Sankhla wrote:
> Hello,
> 
> I have cloned and built the latest rc kernel using the default config but
> on boot, it stucks at "Loading initial ramdisk". I have tried booting after
> removing the "quiet" option from the kernel parameters just before
> selecting the kernel from the grub menu. I have also tried adding
> "dis_ucode_ldr" parameter to the initial parameters but all in vain.
> 

For initramfs, make sure to follow instructions specific to your distro
(search the web if you're unsure). For example, as I'm on Arch, I use
mkinitcpio (see [1]) to generate initramfs after compiling the kernel.

Thanks.

[1]: https://wiki.archlinux.org/title/Mkinitcpio

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Boot stucks at "Loading initial ramdisk"

2023-12-21 Thread Valdis Klētnieks
On Thu, 21 Dec 2023 17:58:23 +0530, Dileep Sankhla said:

> I have cloned and built the latest rc kernel using the default config but
> on boot, it stucks at "Loading initial ramdisk". I have tried booting after
> removing the "quiet" option from the kernel parameters just before
> selecting the kernel from the grub menu.

So when you remove 'quiet', what's the last output you get from the kernel?

You might also take a look at whether the initramfs image was installed to the 
right
location, and whether its size/contents seem reasonable.


pgpcTVRk0GFe4.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: when/how is the schedule() function actually called?

2023-12-14 Thread Billie Alsup (balsup)


> But I don't see any code that is calling the schedule or __schedule function.

I think with a little investigation, you will be able to figure it out.  For 
example, arch/x86/entry/common.c
in function do_syscall_64 calls syscall_entr_from_user_mode and 
syscall_exit_to_user_mode.   I could guess
we eventually reach exit_to_user_mode_loop, which will conditionally call 
schedule() which calls __schedule
(although I didn't investigate this chain, so am just guessing).

I'm a newbie to this stuff as well, but it is not too difficult to follow this. 
 I would guess there are
IDEs available that can help you with diagramming the flow if you don't want to 
manually find things
one layer at a time.  The Documentation folder also has a lot of good 
information.  For example,
Documentation/trace/histogram.rst shows some backtraces with __schedule, and 
you can see
examples of how it is called from do_syscall_64 and ret_from_fork.  Other 
traces are available in
Documentation/trace/ftrace.rst

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


Re: when/how is the schedule() function actually called?

2023-12-10 Thread Dawei Li
Hi Billie,

Thanks for getting back to me!
Many sources mentioned the same thing, but where do I find the code that
supports this?

I followed the comment here:
https://github.com/torvalds/linux/blob/c527f5606aa545233a4d2c6d5c636ed82b8633ef/kernel/sched/core.c#L6536C10-L6536C10
to check all the following files:
arch/x86/entry/entry_32.S
arch/x86/entry/entry_64_compat.S
arch/x86/entry/entry_64.S
arch/x86/entry/entry.S

But I don't see any code that is calling the schedule or __schedule
function.

On Sat, Dec 9, 2023 at 3:10 AM Billie Alsup (balsup) 
wrote:

> >From: Dawei Li 
> >When/how is the schedule() function actually called?
>
> I vaguely recall the actual switch taking place at the end of an
> interrupt,
> and/or during the return from a syscall, or on explicit request (e.g.
> yield).
> Look at __schedule and context_switch functions.
>
>
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: from CoLinux to MoreLinux :D

2023-12-09 Thread Mario Marietto
> a) It's likely that it's an adopted version of the linux kernel so
it's likely also old

Are you sure that you gave a fast read to this page ? --->
https://l4re.org/download/snapshots/

They say :

You are free to use any Linux distribution you like, or even BSDs or any of
its derivatives. But then you should know the game. Especially tool
versions should be recent, as installed on the listed distributions below.

We are confident that the snapshot works on the following distributions:

   - Debian 11 or later
   - Ubuntu 22.04 or later

so,it seems that they found a way to use an updated linux version.
Unfortunately they don't talk about FreeBSD. It deserves more
research,because this is what I'm interested in.

On Sun, Dec 10, 2023 at 4:58 AM Richard 
wrote:

>
>
> On 10.12.23 01:02, Mario Marietto wrote:
> > Thanks. That's exactly what I was looking for. Actually we are trying to
> > boot FreeBSD with xen on our arm 32 Chromebook. But if it fails we could
> > try L4Linux. Yes,they say that's similar to xen,but with some important
> > differences that I haven't read and understood yet.
>
> This is pure speculation because I don't have time to dig deeper into
> L4Linux but I think the whole solution will be worse than Xen. When
> Linux is really run as a process this means:
>
> a) It's likely that it's an adopted version of the linux kernel so it's
> likely also old
>
> b) A process is a strictly defined thing with a clearly defined API that
> is actually designed to do very different things, the things an OS
> Kernel does might fit very bad into that meaning that a lot of the
> behaviour might have to use workaround and might be quite imperformant.
> For example the linux kernel is multithreaded and different kernel
> threads can talk to each other quite easily, can they do the same on L4?
> Might be difficult.
>
>
>
> > Thanks for your
> > invitation to read. Yes,I'm very interested in all the virtualization
> > stuff all around,but I'm not sure that reading a complicated book will
> > help me.
>
> I'm actually sure about that and the answer is no. But "Modern Operating
> Systems" is no complicated book, it's a very easy to read introduction
> for beginners, usually it's read by undergraduate students that have
> never programmed before.
>
> > My training at the college has been totally different,I'm a
> > psychologist. Do you think that one can be able to learn by himself how
> > an operating system works by reading and studying a book found on the
> > Internet,without the support of a teacher ?
>
> Yes, given enough motivation and work ethic. I've never heard even one
> university course on linux kernel programming, my university degree was
> mostly about math
>
> > Do you think that we can remove
> > colleges from the face of the earth ?
>
> No, because lots of people don't have enough motivation, work ethic or
> structure, actually I think the benefit of colleges / universities is
> not really the subject but teaching people the skills to actually
> acquire knowledge themselves and abstract thinking.
>
>
> -- Richard
> >
> > On Sat, Dec 9, 2023 at 8:01 PM Richard  > > wrote:
> >
> > I looked at this,
> >
> > L4 is a family of Microkernels:
> > https://en.wikipedia.org/wiki/L4_microkernel_family
> > 
> >
> > L4Re is a project to let other operating system kernels run as
> > processes
> > on top of a L4 Kernel. But they are still monolithic kernels even
> when
> > you run them on top of another kernel. Actually all this is similar
> > to Xen.
> >
> > Since you are interested in those things I would really recommend
> > reading one of the textbooks. "Modern Operating Systems" by Tanenbaum
> > even has a chapter on exactly this it's called "Are hypervisors
> > microkernels done right?"
> >
> > -- Richard
> >
> >
> > On 09.12.23 14:24, Mario Marietto wrote:
> >  > ---> Neither FreeBSD nor Linux has a microkernel
> >  >
> >  > Can you give a look here ?
> >  >
> >  > https://l4re.org/download/snapshots/
> > 
> >  > >
> >  >
> >  > where it says :
> >  >
> >  > "You are free to use any Linux distribution you like, or even
> > BSDs or
> >  > any of its derivatives"
> >  >
> >  > On Fri, Dec 8, 2023 at 12:53 PM Mario Marietto
> > mailto:marietto2...@gmail.com>
> >  > >>
> > wrote:
> >  >
> >  > Ok but then what it means what I read below (taken from
> > wikipedia) :
> >  >
> >  > ^L4 Linux also allows setting up a virtualized
> >  >  > > environment vaguely
> >  > si

Re: from CoLinux to MoreLinux :D

2023-12-09 Thread Richard



On 10.12.23 01:02, Mario Marietto wrote:
Thanks. That's exactly what I was looking for. Actually we are trying to 
boot FreeBSD with xen on our arm 32 Chromebook. But if it fails we could 
try L4Linux. Yes,they say that's similar to xen,but with some important 
differences that I haven't read and understood yet. 


This is pure speculation because I don't have time to dig deeper into 
L4Linux but I think the whole solution will be worse than Xen. When 
Linux is really run as a process this means:


a) It's likely that it's an adopted version of the linux kernel so it's 
likely also old


b) A process is a strictly defined thing with a clearly defined API that 
is actually designed to do very different things, the things an OS 
Kernel does might fit very bad into that meaning that a lot of the 
behaviour might have to use workaround and might be quite imperformant. 
For example the linux kernel is multithreaded and different kernel 
threads can talk to each other quite easily, can they do the same on L4? 
Might be difficult.




Thanks for your 
invitation to read. Yes,I'm very interested in all the virtualization 
stuff all around,but I'm not sure that reading a complicated book will 
help me. 


I'm actually sure about that and the answer is no. But "Modern Operating 
Systems" is no complicated book, it's a very easy to read introduction 
for beginners, usually it's read by undergraduate students that have 
never programmed before.


My training at the college has been totally different,I'm a 
psychologist. Do you think that one can be able to learn by himself how 
an operating system works by reading and studying a book found on the 
Internet,without the support of a teacher ? 


Yes, given enough motivation and work ethic. I've never heard even one 
university course on linux kernel programming, my university degree was 
mostly about math


Do you think that we can remove 
colleges from the face of the earth ?


No, because lots of people don't have enough motivation, work ethic or 
structure, actually I think the benefit of colleges / universities is 
not really the subject but teaching people the skills to actually 
acquire knowledge themselves and abstract thinking.



-- Richard


On Sat, Dec 9, 2023 at 8:01 PM Richard > wrote:


I looked at this,

L4 is a family of Microkernels:
https://en.wikipedia.org/wiki/L4_microkernel_family


L4Re is a project to let other operating system kernels run as
processes
on top of a L4 Kernel. But they are still monolithic kernels even when
you run them on top of another kernel. Actually all this is similar
to Xen.

Since you are interested in those things I would really recommend
reading one of the textbooks. "Modern Operating Systems" by Tanenbaum
even has a chapter on exactly this it's called "Are hypervisors
microkernels done right?"

-- Richard


On 09.12.23 14:24, Mario Marietto wrote:
 > ---> Neither FreeBSD nor Linux has a microkernel
 >
 > Can you give a look here ?
 >
 > https://l4re.org/download/snapshots/

>
 >
 > where it says :
 >
 > "You are free to use any Linux distribution you like, or even
BSDs or
 > any of its derivatives"
 >
 > On Fri, Dec 8, 2023 at 12:53 PM Mario Marietto
mailto:marietto2...@gmail.com>
 > >>
wrote:
 >
 >     Ok but then what it means what I read below (taken from
wikipedia) :
 >
 >     ^L4 Linux also allows setting up a virtualized
 >     > environment vaguely
 >     similar to Xen > or Kernel-bas
 >     >
 >     ed Virtual Machine
 >     > (KVM),
 >     but a few significant differences exist^// between the intent
of Xen
 >     and L^4 Linux.
 >
 >     Il ven 8 dic 2023, 12:13 Richard
mailto:richard_siegfr...@systemli.org>
 >     >> ha scritto:
 >
 >
 >
 >         On 08.12.23 09:11, Mario Marietto wrote:
 >          > With l4linux (or redox) can I boot and run 2 linux distros
 >         using the
 >          > same kernel ? I ask because the developers talk about
 >         virtualization and
 >          > because CoLinux allows us to

Re: from CoLinux to MoreLinux :D

2023-12-09 Thread Mario Marietto
Errata corrige : without the support of a teacher.

On Sun, Dec 10, 2023 at 1:02 AM Mario Marietto 
wrote:

> Thanks. That's exactly what I was looking for. Actually we are trying to
> boot FreeBSD with xen on our arm 32 Chromebook. But if it fails we could
> try L4Linux. Yes,they say that's similar to xen,but with some important
> differences that I haven't read and understood yet. Thanks for your
> invitation to read. Yes,I'm very interested in all the virtualization stuff
> all around,but I'm not sure that reading a complicated book will help me.
> My training at the college has been totally different,I'm a psychologist.
> Do you think that one can be able to learn by himself how an operating
> system works by reading and studying a book found on the Internet,with the
> support of a teacher ? Do you think that we can remove colleges from the
> face of the earth ?
>
> On Sat, Dec 9, 2023 at 8:01 PM Richard 
> wrote:
>
>> I looked at this,
>>
>> L4 is a family of Microkernels:
>> https://en.wikipedia.org/wiki/L4_microkernel_family
>>
>> L4Re is a project to let other operating system kernels run as processes
>> on top of a L4 Kernel. But they are still monolithic kernels even when
>> you run them on top of another kernel. Actually all this is similar to
>> Xen.
>>
>> Since you are interested in those things I would really recommend
>> reading one of the textbooks. "Modern Operating Systems" by Tanenbaum
>> even has a chapter on exactly this it's called "Are hypervisors
>> microkernels done right?"
>>
>> -- Richard
>>
>>
>> On 09.12.23 14:24, Mario Marietto wrote:
>> > ---> Neither FreeBSD nor Linux has a microkernel
>> >
>> > Can you give a look here ?
>> >
>> > https://l4re.org/download/snapshots/ <
>> https://l4re.org/download/snapshots/>
>> >
>> > where it says :
>> >
>> > "You are free to use any Linux distribution you like, or even BSDs or
>> > any of its derivatives"
>> >
>> > On Fri, Dec 8, 2023 at 12:53 PM Mario Marietto > > > wrote:
>> >
>> > Ok but then what it means what I read below (taken from wikipedia) :
>> >
>> > ^L4 Linux also allows setting up a virtualized
>> >  environment vaguely
>> > similar to Xen  or Kernel-bas
>> > 
>> > ed Virtual Machine
>> >  (KVM),
>> > but a few significant differences exist^// between the intent of Xen
>> > and L^4 Linux.
>> >
>> > Il ven 8 dic 2023, 12:13 Richard > > > ha scritto:
>> >
>> >
>> >
>> > On 08.12.23 09:11, Mario Marietto wrote:
>> >  > With l4linux (or redox) can I boot and run 2 linux distros
>> > using the
>> >  > same kernel ? I ask because the developers talk about
>> > virtualization and
>> >  > because CoLinux allows us to boot Linux while using Windows
>> >  > What I'm very interested to achieve is to run Linux as a
>> > process under
>> >  > FreeBSD or vice versa,using the best of those two
>> microkernels.
>> >
>> > Neither FreeBSD nor Linux has a microkernel. From all your
>> > questions I
>> > think it would be helpful to read up on some Operating System
>> > Theory
>> > before you go on. I can recommend "Operating Systems - Three
>> Easy
>> > Pieces"
>> > (
>> https://techiefood4u.files.wordpress.com/2020/02/operating_systems_three_easy_pieces.pdf
>> <
>> https://techiefood4u.files.wordpress.com/2020/02/operating_systems_three_easy_pieces.pdf
>> >
>> > )
>> >
>> > It's almost as good as the Tanenbaum Classic, but free.
>> >
>> > -- Richard
>> >
>> >
>> >  >
>> >  >
>> >  >
>> >  > On Fri, Dec 8, 2023 at 2:15 AM > > 
>> >  > >>
>> > wrote:
>> >  >
>> >  > On Mon, Dec 4, 2023 at 1:02 PM Mario Marietto
>> >  > mailto:marietto2...@gmail.com>
>> > > >>>
>> > wrote:
>> >  >  >
>> >  >  > What is this ?
>> >  >  >
>> >  >  >
>> > https://l4re.org/download/snapshots/pre-built-images/arm-v7/
>> > 
>> >  >
>> >   > > >
>> >  >  >
>> >  >
>> >  > Thats a micro-kernel, sort of like GNU Hurd.
>> >  >
>> >  > theres also
>> >  > https://doc.redox-os.org/book/ch04-01-microkernels.html
>> > 

  1   2   3   4   5   6   7   8   9   10   >