Re: Should I return NOTIFY_DONE always from restart handler?

2020-03-24 Thread Pranay Srivastava
Hello,

I believe you'll break the "chain" if you return an error. You might
have registered as the last
one so probably nothing would break but if someone registers on the
notifier after your module
did then that won't receive the notification if you throw an error and
break the chain.

Regards,

On Tue, Mar 24, 2020 at 9:37 PM Tomek The Messenger
 wrote:
>
> Hi
> There is such struct as 'notifier_block'. It has member 'notifier_call' where 
> You assign pointer to your function (handler) and priority. Then You register 
> such notifier block to restart handler list.
> Then when You type in linux reboot Your function might be invoked (depends on 
> priority you set and if You don't have registered arm_pm_restart function 
> which is typically done through device tree) .
> My question is should I always return NOTIFY_DONE from my restart handler? Or 
> can I return some error code? In fact this doesn't make sense to return any 
> other code value as Your restart handler has to succeed always in order not 
> to halt system and not to do manually recovery by power off/on.
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
---P.K.S

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


Should I return NOTIFY_DONE always from restart handler?

2020-03-24 Thread Tomek The Messenger
Hi
There is such struct as 'notifier_block'. It has member 'notifier_call'
where You assign pointer to your function (handler) and priority. Then You
register such notifier block to restart handler list.
Then when You type in linux reboot Your function might be invoked (depends
on priority you set and if You don't have registered arm_pm_restart
function which is typically done through device tree) .
My question is should I always return NOTIFY_DONE from my restart handler?
Or can I return some error code? In fact this doesn't make sense to return
any other code value as Your restart handler has to succeed always in order
not to halt system and not to do manually recovery by power off/on.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


RE: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Pelle Windestam
> To: Pelle Windestam 
> Cc: kernelnewbies@kernelnewbies.org
> Subject: Re: Accessing rpmsg_device in sysfs attribute functions
> 
> On Tue, Mar 24, 2020 at 01:05:48PM +, Pelle Windestam wrote:
> > > From: Greg KH 
> > > Sent: Tuesday, 24 March 2020 13:31
> > > To: Pelle Windestam 
> > > Cc: kernelnewbies@kernelnewbies.org
> > > Subject: Re: Accessing rpmsg_device in sysfs attribute functions
> > >
> > > On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote:
> > > > > On Tue, Mar 24, 2020 at 05:34:44AM +, Pelle Windestam wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am trying to develop a simple driver for the rpmsg bus, in
> > > > > > order to send
> > > > > various commands from user space in Linux to a secondary CPU (A
> > > > > Cortex
> > > M4).
> > > > > I'm trying to keep things as simple as possible, so my idea was
> > > > > to create a driver that just has a few attributes which can be
> > > > > set in /sys which would trigger commands to be sent to the M4
> > > > > CPU. I have the communication between the CPU:s up and running,
> > > > > but where I'm having trouble moving forward is how to access the
> > > > > "struct rpmsg_device *" that I need in order to communicate with
> > > > > the endpoint for the M4 CPU from the store/show function of the
> > > > > sysfs attributes. What my driver does is to register a
> > > > > rpmsg_driver in the init
> > > > > function:
> > > > > >
> > > > > > register_rpmsg_driver(_rpmsg_driver);
> > > > > >
> > > > > > the device_driver member of my rpmsg_driver struct has its
> > > > > > groups member
> > > > > set to my driver attribute groups array:
> > > > > > static struct rpmsg_driver pwm_rpmsg_driver = {
> > > > > > .probe = pwm_rpmsg_probe,
> > > > > > .remove = pwm_rpmsg_remove,
> > > > > > .callback = pwm_rpmsg_cb,
> > > > > > .id_table = pwm_rpmsg_device_id_table,
> > > > > > .drv = {
> > > > > > .groups = driver_pwm_groups,
> > > > > > .name = "pwm_rpmsg",
> > > > > > },
> > > > > > };
> > > > > >
> > > > > > My issue is that that I am not sure how to access the struct
> > > > > > "rpmsg_device
> > > > > *" (i.e. from the probe() function) in the show/store functions
> > > > > for the sysfs attributes, which have a "struct device_driver *"
> argument:
> > > > >
> > > > > That is because you have created a driver attribute, not a
> > > > > device
> > > attribute.
> > > > > Create device attributes and you should be fine, they bind to
> > > > > the device your driver is passed.
> > > >
> > > > Thanks! Changing them to device attributes was a breeze. Now I am
> > > > slightly confused about the "struct device *" argument to the
> > > > store/show functions. I was under the impression that this would
> > > > be the "struct device" in the struct rpmsg_device, (which would
> > > > let me get the struct rpmsg_device using container_of()?), but it
> > > > appears to be some completely other device (by looking at the
> > > > pointer address). I have tried searching the kernel code for
> > > > similar example, but I have not found anything so far. It feels
> > > > like I am stumbling a bit in the dark here, looking for my
> rpmsg_device.
> > >
> > > It's a bit hard to figure out what exactly you are doing here
> > > without a pointer to the code itself :)
> > >
> > > Are you sure you aren't pointing the platform device accidentally?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I suppose anything is possible  Here is the actual code if you want to
> have a look:
> > https://gist.github.com/iceaway/9900a9c2dd221eb836c5acda49f5d688
> 
> Odd, that "should" work.  But the pwm core is strange, I suggest posting it
> to the pwm driver mailing list and asking for help there, as there might be
> some odd "wrapper" structures involved here as can be seen by the pwm core
> sysfs file accesses.
> 
> good luck!
> 

I do no think that the PWM subsystem actually has anything to do with it, I 
only have "pwm" in the name because it will control a PWM signal via the M4 
CPU. Otherwise it's all via the rpmsg driver. Rpmsg does not seem to have a 
mailing list of its own.

I will do some more digging. Thanks for the help!

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


Re: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Greg KH
On Tue, Mar 24, 2020 at 01:05:48PM +, Pelle Windestam wrote:
> > From: Greg KH 
> > Sent: Tuesday, 24 March 2020 13:31
> > To: Pelle Windestam 
> > Cc: kernelnewbies@kernelnewbies.org
> > Subject: Re: Accessing rpmsg_device in sysfs attribute functions
> > 
> > On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote:
> > > > On Tue, Mar 24, 2020 at 05:34:44AM +, Pelle Windestam wrote:
> > > > > Hi,
> > > > >
> > > > > I am trying to develop a simple driver for the rpmsg bus, in order
> > > > > to send
> > > > various commands from user space in Linux to a secondary CPU (A Cortex
> > M4).
> > > > I'm trying to keep things as simple as possible, so my idea was to
> > > > create a driver that just has a few attributes which can be set in
> > > > /sys which would trigger commands to be sent to the M4 CPU. I have
> > > > the communication between the CPU:s up and running, but where I'm
> > > > having trouble moving forward is how to access the "struct
> > > > rpmsg_device *" that I need in order to communicate with the
> > > > endpoint for the M4 CPU from the store/show function of the sysfs
> > > > attributes. What my driver does is to register a rpmsg_driver in the
> > > > init
> > > > function:
> > > > >
> > > > > register_rpmsg_driver(_rpmsg_driver);
> > > > >
> > > > > the device_driver member of my rpmsg_driver struct has its groups
> > > > > member
> > > > set to my driver attribute groups array:
> > > > > static struct rpmsg_driver pwm_rpmsg_driver = {
> > > > >   .probe = pwm_rpmsg_probe,
> > > > >   .remove = pwm_rpmsg_remove,
> > > > >   .callback = pwm_rpmsg_cb,
> > > > >   .id_table = pwm_rpmsg_device_id_table,
> > > > >   .drv = {
> > > > >   .groups = driver_pwm_groups,
> > > > >   .name = "pwm_rpmsg",
> > > > >   },
> > > > > };
> > > > >
> > > > > My issue is that that I am not sure how to access the struct
> > > > > "rpmsg_device
> > > > *" (i.e. from the probe() function) in the show/store functions for
> > > > the sysfs attributes, which have a "struct device_driver *" argument:
> > > >
> > > > That is because you have created a driver attribute, not a device
> > attribute.
> > > > Create device attributes and you should be fine, they bind to the
> > > > device your driver is passed.
> > >
> > > Thanks! Changing them to device attributes was a breeze. Now I am
> > > slightly confused about the "struct device *" argument to the
> > > store/show functions. I was under the impression that this would be
> > > the "struct device" in the struct rpmsg_device, (which would let me
> > > get the struct rpmsg_device using container_of()?), but it appears to
> > > be some completely other device (by looking at the pointer address). I
> > > have tried searching the kernel code for similar example, but I have
> > > not found anything so far. It feels like I am stumbling a bit in the
> > > dark here, looking for my rpmsg_device.
> > 
> > It's a bit hard to figure out what exactly you are doing here without a
> > pointer to the code itself :)
> > 
> > Are you sure you aren't pointing the platform device accidentally?
> > 
> > thanks,
> > 
> > greg k-h
> 
> I suppose anything is possible  Here is the actual code if you want to have 
> a look:
> https://gist.github.com/iceaway/9900a9c2dd221eb836c5acda49f5d688

Odd, that "should" work.  But the pwm core is strange, I suggest posting
it to the pwm driver mailing list and asking for help there, as there
might be some odd "wrapper" structures involved here as can be seen by
the pwm core sysfs file accesses.

good luck!

greg k-h

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


RE: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Pelle Windestam
> From: Greg KH 
> Sent: Tuesday, 24 March 2020 13:31
> To: Pelle Windestam 
> Cc: kernelnewbies@kernelnewbies.org
> Subject: Re: Accessing rpmsg_device in sysfs attribute functions
> 
> On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote:
> > > On Tue, Mar 24, 2020 at 05:34:44AM +, Pelle Windestam wrote:
> > > > Hi,
> > > >
> > > > I am trying to develop a simple driver for the rpmsg bus, in order
> > > > to send
> > > various commands from user space in Linux to a secondary CPU (A Cortex
> M4).
> > > I'm trying to keep things as simple as possible, so my idea was to
> > > create a driver that just has a few attributes which can be set in
> > > /sys which would trigger commands to be sent to the M4 CPU. I have
> > > the communication between the CPU:s up and running, but where I'm
> > > having trouble moving forward is how to access the "struct
> > > rpmsg_device *" that I need in order to communicate with the
> > > endpoint for the M4 CPU from the store/show function of the sysfs
> > > attributes. What my driver does is to register a rpmsg_driver in the
> > > init
> > > function:
> > > >
> > > > register_rpmsg_driver(_rpmsg_driver);
> > > >
> > > > the device_driver member of my rpmsg_driver struct has its groups
> > > > member
> > > set to my driver attribute groups array:
> > > > static struct rpmsg_driver pwm_rpmsg_driver = {
> > > > .probe = pwm_rpmsg_probe,
> > > > .remove = pwm_rpmsg_remove,
> > > > .callback = pwm_rpmsg_cb,
> > > > .id_table = pwm_rpmsg_device_id_table,
> > > > .drv = {
> > > > .groups = driver_pwm_groups,
> > > > .name = "pwm_rpmsg",
> > > > },
> > > > };
> > > >
> > > > My issue is that that I am not sure how to access the struct
> > > > "rpmsg_device
> > > *" (i.e. from the probe() function) in the show/store functions for
> > > the sysfs attributes, which have a "struct device_driver *" argument:
> > >
> > > That is because you have created a driver attribute, not a device
> attribute.
> > > Create device attributes and you should be fine, they bind to the
> > > device your driver is passed.
> >
> > Thanks! Changing them to device attributes was a breeze. Now I am
> > slightly confused about the "struct device *" argument to the
> > store/show functions. I was under the impression that this would be
> > the "struct device" in the struct rpmsg_device, (which would let me
> > get the struct rpmsg_device using container_of()?), but it appears to
> > be some completely other device (by looking at the pointer address). I
> > have tried searching the kernel code for similar example, but I have
> > not found anything so far. It feels like I am stumbling a bit in the
> > dark here, looking for my rpmsg_device.
> 
> It's a bit hard to figure out what exactly you are doing here without a
> pointer to the code itself :)
> 
> Are you sure you aren't pointing the platform device accidentally?
> 
> thanks,
> 
> greg k-h

I suppose anything is possible  Here is the actual code if you want to have a 
look:
https://gist.github.com/iceaway/9900a9c2dd221eb836c5acda49f5d688

//Pelle

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


Re: Finding bugs/issues to work on

2020-03-24 Thread Greg KH
On Tue, Mar 24, 2020 at 04:49:29PM +0530, Suraj Upadhyay wrote:
> Hii newbies,
> I just started studying for linux-kernel development although I am
> not completely new to open source technologies. I wanted to clarify my
> doubts in the following things
> 1. Where can I find issues/tickets regarding linux-kernel, to work on ?

It depends on the part of the kernel you are interested in, what part is
that?

> 2. What's the best resource to get started on linux-kernel development ?
> I started reading kernel-newbies guides, though.

That's a great start, what is wrong with that?

good luck,

greg k-h

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


Re: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Greg KH
On Tue, Mar 24, 2020 at 12:02:15PM +, Pelle Windestam wrote:
> > On Tue, Mar 24, 2020 at 05:34:44AM +, Pelle Windestam wrote:
> > > Hi,
> > >
> > > I am trying to develop a simple driver for the rpmsg bus, in order to send
> > various commands from user space in Linux to a secondary CPU (A Cortex M4).
> > I'm trying to keep things as simple as possible, so my idea was to create a
> > driver that just has a few attributes which can be set in /sys which would
> > trigger commands to be sent to the M4 CPU. I have the communication between
> > the CPU:s up and running, but where I'm having trouble moving forward is how
> > to access the "struct rpmsg_device *" that I need in order to communicate
> > with the endpoint for the M4 CPU from the store/show function of the sysfs
> > attributes. What my driver does is to register a rpmsg_driver in the init
> > function:
> > >
> > > register_rpmsg_driver(_rpmsg_driver);
> > >
> > > the device_driver member of my rpmsg_driver struct has its groups member
> > set to my driver attribute groups array:
> > > static struct rpmsg_driver pwm_rpmsg_driver = {
> > >   .probe = pwm_rpmsg_probe,
> > >   .remove = pwm_rpmsg_remove,
> > >   .callback = pwm_rpmsg_cb,
> > >   .id_table = pwm_rpmsg_device_id_table,
> > >   .drv = {
> > >   .groups = driver_pwm_groups,
> > >   .name = "pwm_rpmsg",
> > >   },
> > > };
> > >
> > > My issue is that that I am not sure how to access the struct "rpmsg_device
> > *" (i.e. from the probe() function) in the show/store functions for the 
> > sysfs
> > attributes, which have a "struct device_driver *" argument:
> > 
> > That is because you have created a driver attribute, not a device attribute.
> > Create device attributes and you should be fine, they bind to the device 
> > your
> > driver is passed.
> 
> Thanks! Changing them to device attributes was a breeze. Now I am
> slightly confused about the "struct device *" argument to the
> store/show functions. I was under the impression that this would be
> the "struct device" in the struct rpmsg_device, (which would let me
> get the struct rpmsg_device using container_of()?), but it appears to
> be some completely other device (by looking at the pointer address). I
> have tried searching the kernel code for similar example, but I have
> not found anything so far. It feels like I am stumbling a bit in the
> dark here, looking for my rpmsg_device.

It's a bit hard to figure out what exactly you are doing here without a
pointer to the code itself :)

Are you sure you aren't pointing the platform device accidentally?

thanks,

greg k-h

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


RE: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Pelle Windestam
> On Tue, Mar 24, 2020 at 05:34:44AM +, Pelle Windestam wrote:
> > Hi,
> >
> > I am trying to develop a simple driver for the rpmsg bus, in order to send
> various commands from user space in Linux to a secondary CPU (A Cortex M4).
> I'm trying to keep things as simple as possible, so my idea was to create a
> driver that just has a few attributes which can be set in /sys which would
> trigger commands to be sent to the M4 CPU. I have the communication between
> the CPU:s up and running, but where I'm having trouble moving forward is how
> to access the "struct rpmsg_device *" that I need in order to communicate
> with the endpoint for the M4 CPU from the store/show function of the sysfs
> attributes. What my driver does is to register a rpmsg_driver in the init
> function:
> >
> > register_rpmsg_driver(_rpmsg_driver);
> >
> > the device_driver member of my rpmsg_driver struct has its groups member
> set to my driver attribute groups array:
> > static struct rpmsg_driver pwm_rpmsg_driver = {
> > .probe = pwm_rpmsg_probe,
> > .remove = pwm_rpmsg_remove,
> > .callback = pwm_rpmsg_cb,
> > .id_table = pwm_rpmsg_device_id_table,
> > .drv = {
> > .groups = driver_pwm_groups,
> > .name = "pwm_rpmsg",
> > },
> > };
> >
> > My issue is that that I am not sure how to access the struct "rpmsg_device
> *" (i.e. from the probe() function) in the show/store functions for the sysfs
> attributes, which have a "struct device_driver *" argument:
> 
> That is because you have created a driver attribute, not a device attribute.
> Create device attributes and you should be fine, they bind to the device your
> driver is passed.

Thanks! Changing them to device attributes was a breeze. Now I am slightly 
confused about the "struct device *" argument to the store/show functions. I 
was under the impression that this would be the "struct device" in the struct 
rpmsg_device, (which would let me get the struct rpmsg_device using 
container_of()?), but it appears to be some completely other device (by looking 
at the pointer address). I have tried searching the kernel code for similar 
example, but I have not found anything so far. It feels like I am stumbling a 
bit in the dark here, looking for my rpmsg_device.

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


Re: Finding bugs/issues to work on

2020-03-24 Thread Robert P. J. Day
On Tue, 24 Mar 2020, Suraj Upadhyay wrote:

> Hii newbies,
>     I just started studying for linux-kernel development although I am not
> completely new to open source technologies. I wanted to clarify my doubts in 
> the
> following things
> 1. Where can I find issues/tickets regarding linux-kernel, to work on ?
> 2. What's the best resource to get started on linux-kernel development ?
> I started reading kernel-newbies guides, though.

  i make this suggestion on a semi-regular basis ... if you want
something that desperately needs doing, work on improving the
documentation. there is never a lack of docs that need improving, and
it gives you a chance to *safely* learn a lot of new stuff.

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


Finding bugs/issues to work on

2020-03-24 Thread Suraj Upadhyay
Hii newbies,
I just started studying for linux-kernel development although I am
not completely new to open source technologies. I wanted to clarify my
doubts in the following things
1. Where can I find issues/tickets regarding linux-kernel, to work on ?
2. What's the best resource to get started on linux-kernel development ?
I started reading kernel-newbies guides, though.

Grateful for your time and responses,
Yours sincerely,
A Kernel-Newbie.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Greg KH
On Tue, Mar 24, 2020 at 10:49:46AM +0100, Martin Kaiser wrote:
> Hi Greg,
> 
> Thus wrote Greg KH (g...@kroah.com):
> 
> > That is because you have created a driver attribute, not a device
> > attribute.  Create device attributes and you should be fine, they bind
> > to the device your driver is passed.
> 
> could you point me to an example in the kernel tree where this is done
> correctly for a platform device?
> 
> I had a look at
> 
> http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
> 
> but I couldn't figure out how to create device attributes in a simple
> platform driver that binds to a platform device.

Look at commit d5a4f0f1 ("Input: axp20x-pek - convert driver to use
dev_groups") in the 5.4 kernel as an example of how to use the correct
api here.

Hope this helps,

greg k-h

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


Re: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Martin Kaiser
Hi Greg,

Thus wrote Greg KH (g...@kroah.com):

> That is because you have created a driver attribute, not a device
> attribute.  Create device attributes and you should be fine, they bind
> to the device your driver is passed.

could you point me to an example in the kernel tree where this is done
correctly for a platform device?

I had a look at

http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

but I couldn't figure out how to create device attributes in a simple
platform driver that binds to a platform device.

Thanks a lot for your help,

   Martin

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


Re: Accessing rpmsg_device in sysfs attribute functions

2020-03-24 Thread Greg KH
On Tue, Mar 24, 2020 at 05:34:44AM +, Pelle Windestam wrote:
> Hi,
> 
> I am trying to develop a simple driver for the rpmsg bus, in order to send 
> various commands from user space in Linux to a secondary CPU (A Cortex M4). 
> I'm trying to keep things as simple as possible, so my idea was to create a 
> driver that just has a few attributes which can be set in /sys which would 
> trigger commands to be sent to the M4 CPU. I have the communication between 
> the CPU:s up and running, but where I'm having trouble moving forward is how 
> to access the "struct rpmsg_device *" that I need in order to communicate 
> with the endpoint for the M4 CPU from the store/show function of the sysfs 
> attributes. What my driver does is to register a rpmsg_driver in the init 
> function:
> 
> register_rpmsg_driver(_rpmsg_driver);
> 
> the device_driver member of my rpmsg_driver struct has its groups member set 
> to my driver attribute groups array:
> static struct rpmsg_driver pwm_rpmsg_driver = {
>   .probe = pwm_rpmsg_probe,
>   .remove = pwm_rpmsg_remove,
>   .callback = pwm_rpmsg_cb,
>   .id_table = pwm_rpmsg_device_id_table,
>   .drv = {
>   .groups = driver_pwm_groups,
>   .name = "pwm_rpmsg",
>   },
> };
> 
> My issue is that that I am not sure how to access the struct "rpmsg_device *" 
> (i.e. from the probe() function) in the show/store functions for the sysfs 
> attributes, which have a "struct device_driver *" argument:

That is because you have created a driver attribute, not a device
attribute.  Create device attributes and you should be fine, they bind
to the device your driver is passed.

good luck!

greg k-h

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