Re: wait_event_* and wake_up_*
On Jul 22, 2014 10:41 PM, Mohammad Merajul Islam Molla meraj.eni...@gmail.com wrote: You may find this useful - http://www.makelinux.net/ldd3/chp-6-sect-2 Thanks Meraj, that is really helpful. -- Thanks, -Meraj On Wed, Jul 23, 2014 at 8:12 AM, Pranith Kumar pran...@gatech.edu wrote: Hello, Could someone point me to good documentation about the wait_event_* and wake_up_* event family APIs? I tried searching and nothing concrete shows up. In particular: When do we use wake_up_interruptible()? Does wake_up(wq) wake up all the threads which are waiting on that work queue? Is the waking up of threads sequential? That should suffice for now I guess :) Regards, -- Pranith ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: question about kref API
-Original Message-
From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-
boun...@kernelnewbies.org] On Behalf Of Jeff Haran
Sent: Wednesday, July 23, 2014 10:33 AM
To: 'Greg KH'
Cc: kernelnewbies@kernelnewbies.org
Subject: RE: question about kref API
-Original Message-
From: Greg KH [mailto:g...@kroah.com]
Sent: Tuesday, July 22, 2014 4:47 PM
To: Jeff Haran
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: question about kref API
On Tue, Jul 22, 2014 at 05:25:03PM +, Jeff Haran wrote:
-Original Message-
From: Greg KH [mailto:g...@kroah.com]
Sent: Monday, July 21, 2014 7:18 PM
To: Jeff Haran
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: question about kref API
On Tue, Jul 22, 2014 at 12:27:20AM +, Jeff Haran wrote:
Hi,
I've been reading Documentation/kref.txt in order to understand
the usage of this API. There is part of this documentation that
I am having difficulty understanding and was hoping somebody on
this list could clarify this. One of my assumptions in reading
this is that the expected usage of this API is that for a given
object embedding a kref, once the object has been initialized
the number of calls to put a given instance of an object
should never exceed the number of calls to get that same instance.
If it does, the object will be cleaned up and deleted from the
system, so you no longer have a valid pointer.
Maybe that's the root of my misunderstanding, but my assumption
is that calls to kref_get() and kref_put() are expected to be
made in pairs for a given instance of struct kref. If this is
wrong, please let me know.
pairs in that the same number must be called in order for things
to work properly.
Kref.txt includes some sample code that discusses using a mutex
to serialize the execution of its get_entry() and put_entry()
functions:
146 static DEFINE_MUTEX(mutex);
147 static LIST_HEAD(q);
148 struct my_data
149 {
150 struct kref refcount;
151 struct list_head link;
152 };
153
154 static struct my_data *get_entry()
155 {
156 struct my_data *entry = NULL;
157 mutex_lock(mutex);
158 if (!list_empty(q)) {
159 entry = container_of(q.next, struct my_data,
link);
160 kref_get(entry-refcount);
161 }
162 mutex_unlock(mutex);
163 return entry;
164 }
165
166 static void release_entry(struct kref *ref)
167 {
168 struct my_data *entry = container_of(ref, struct my_data,
refcount);
169
170 list_del(entry-link);
171 kfree(entry);
172 }
173
174 static void put_entry(struct my_data *entry)
175 {
176 mutex_lock(mutex);
177 kref_put(entry-refcount, release_entry);
178 mutex_unlock(mutex);
179 }
The sample code does not show the creation of the link list
headed by q,
That is done there in the static initializer.
[meta comment, please properly wrap your lines...]
Apologies on the long lines of my most recent post.
While composing it, I terminated each line with a return at short line lengths.
But then Outlook crams them all back together again when I hit send.
I'll do better next time.
You are referring to line 147 here, right? That creates an empty
list if I am following the code correctly.
Yes.
What I meant was that the sample code doesn't show how instances of
struct my_data get initialized and inserted into the list at q.
Makes sense to leave that out for brevity I suppose and you've made
it clear below that for this to work right a call to kref_init()
must have been made on the refcount fields of any struct my_data
instances that got put into the list headed by q. Thanks.
Yes, that code is left as an exercise for the reader. Or you can just
look at the kernel where it is used in many places directly :)
At this point it's rule (3) that I am still struggling with a bit:
50 3) If the code attempts to gain a reference to a kref-ed structure
51without already holding a valid pointer, it must serialize access
52where a kref_put() cannot occur during the kref_get(), and the
53structure must remain valid during the kref_get().
In this example, every call to put_entry() results in locking and
unlocking the mutex. But if I am following this right, that is only
because the entry at the head of the list is removed from the list
when and only when the last reference to it is released.
It has nothing to do with a list, don't get hung up on a list with a
kref, it's not needed, just used as an example here.
If the list_del() happened for some
Re: question about kref API
On Wed, Jul 23, 2014 at 05:33:19PM +, Jeff Haran wrote: Clearly there are potential performance benefits in not needing to take locks or mutexes when they are not necessary. Of course there are. But trust me, you need to use a lock here, as the document tries to explain, otherwise your code is broken. If you could elaborate on where the race condition is here, I think you'd being doing both me and the community a great service. Nice try with the Do it for the community because I don't understand this! appeal, that doesn't work for me, sorry... I think you need to go look at the code closer and not get confused with functions like kref_sub(), which you should never use unless you know exactly what you are doing, and even then, I strongly discourage their use (which is why there are only 2 users in the kernel.) Focus on the normal kref functions, and again, look at in-kernel users for examples of how to use this properly. Also, what are you trying to gain here, do you want to use a kref in your code? If so, please submit patches showing your usage and I will be glad to review them. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: question about kref API
-Original Message- From: 'Greg KH' [mailto:g...@kroah.com] Sent: Wednesday, July 23, 2014 10:48 AM To: Jeff Haran Cc: kernelnewbies@kernelnewbies.org Subject: Re: question about kref API On Wed, Jul 23, 2014 at 05:33:19PM +, Jeff Haran wrote: Clearly there are potential performance benefits in not needing to take locks or mutexes when they are not necessary. Of course there are. But trust me, you need to use a lock here, as the document tries to explain, otherwise your code is broken. If you could elaborate on where the race condition is here, I think you'd being doing both me and the community a great service. Nice try with the Do it for the community because I don't understand this! appeal, that doesn't work for me, sorry... Boy, I try to be as deferential as possible here and you come back with this snarky response. My experience is when software developers can't or won't explain how their code works, it's because they don't understand it themselves. I won't bother you again. Thanks for your time. I think you need to go look at the code closer and not get confused with functions like kref_sub(), which you should never use unless you know exactly what you are doing, and even then, I strongly discourage their use (which is why there are only 2 users in the kernel.) Focus on the normal kref functions, and again, look at in-kernel users for examples of how to use this properly. Also, what are you trying to gain here, do you want to use a kref in your code? If so, please submit patches showing your usage and I will be glad to review them. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: question about kref API
On Wed, Jul 23, 2014 at 05:55:50PM +, Jeff Haran wrote: -Original Message- From: 'Greg KH' [mailto:g...@kroah.com] Sent: Wednesday, July 23, 2014 10:48 AM To: Jeff Haran Cc: kernelnewbies@kernelnewbies.org Subject: Re: question about kref API On Wed, Jul 23, 2014 at 05:33:19PM +, Jeff Haran wrote: Clearly there are potential performance benefits in not needing to take locks or mutexes when they are not necessary. Of course there are. But trust me, you need to use a lock here, as the document tries to explain, otherwise your code is broken. If you could elaborate on where the race condition is here, I think you'd being doing both me and the community a great service. Nice try with the Do it for the community because I don't understand this! appeal, that doesn't work for me, sorry... Boy, I try to be as deferential as possible here and you come back with this snarky response. Snarky? You were asking me to take time and personally walk you through the kref code and your misconceptions of it. I've written this document, given numerous presentations on it, wrote a published conference paper on the topic, as well as maintining the kernel code for over a decade now. Trying to say do it for the community implies my previous work was somehow insufficient and I should do more to appease your specific need. And that need is still unknown to me, you never said _why_ you wanted to understand the kref code. Which is important to me. My experience is when software developers can't or won't explain how their code works, it's because they don't understand it themselves. Yeah, that's it, really, I don't understand it at all, talk about snark :) I asked you to read the in-kernel usage of the code, instead of this contrived example code, which you didn't do. I asked you to provide a use-case or example of where you wanted to use this code, which you didn't do. Instead you insist that I educate you without doing much work on your own, which is not how a community works, sorry. Best of luck in your education process. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk or pr_level?
1. No. Depending on what subsystem your are printing logs from you should use different functions for logging. In the networking subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will always work and is always preferred over printk. 2. Use pr_debug. On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva raphaelcampos...@gmail.com wrote: Hello guys, 1) If I use printk(KERN_LEVEL...) the checkpatch warns me: WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... So, pr_devel() is the correct way to print a debug level msg? 2) if pr_level is the correct way, what about KERN_DEFAULT ? If I don't put the kern_level (printk(Hello);) WARNING: printk() should include KERN_ facility level if I put KERN_DEFAULT: WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... But for KERN_DEFAULT, there isn't a macro pr_level like pr_devel(). Can anyone show me the correct way? tks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk or pr_level?
On Wed, Jul 23, 2014 at 8:34 PM, Kristofer Hallin kristofer.hal...@gmail.com wrote: 1. No. Depending on what subsystem your are printing logs from you should use different functions for logging. In the networking subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will always work and is always preferred over printk. By default, pr_debug is an empty macro unless you add -DDEBUG to CFLAGS. So in addition to what Kristofer said, be sure you compile your module/kernel with that flag enabled. Cheers. 2. Use pr_debug. On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva raphaelcampos...@gmail.com wrote: Hello guys, 1) If I use printk(KERN_LEVEL...) the checkpatch warns me: WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... So, pr_devel() is the correct way to print a debug level msg? 2) if pr_level is the correct way, what about KERN_DEFAULT ? If I don't put the kern_level (printk(Hello);) WARNING: printk() should include KERN_ facility level if I put KERN_DEFAULT: WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... But for KERN_DEFAULT, there isn't a macro pr_level like pr_devel(). Can anyone show me the correct way? tks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk or pr_level?
On Jul 23 2014, Kristofer Hallin wrote: 1. No. Depending on what subsystem your are printing logs from you should use different functions for logging. In the networking subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will always work and is always preferred over printk. Why? No snark intended here, just confused curiousity. It would seem to me that one common method of printing would be better than a different one for each subsystem, each needing to be individually remembered, and potentially having its own bugs\b\b\b\bquirks. The kernel is complex enough, without adding uneeded extra. And yes, this begs the question of why you want to print messages from the kernel, whether they ought to be conditional and/or rate limited, etc. etc. Clearly the recommendation of pr_debug() suggests someone thinks they should be at least somewhat conditional... 2. Use pr_debug. On Wed, Jul 23, 2014 at 8:16 PM, Raphael Silva raphaelcampos...@gmail.com wrote: Hello guys, 1) If I use printk(KERN_LEVEL...) the checkpatch warns me: WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... So, pr_devel() is the correct way to print a debug level msg? 2) if pr_level is the correct way, what about KERN_DEFAULT ? If I don't put the kern_level (printk(Hello);) WARNING: printk() should include KERN_ facility level if I put KERN_DEFAULT: WARNING: Prefer [subsystem eg: netdev]_default([subsystem]dev, ... then dev_default(dev, ... then pr_default(... to printk(KERN_DEFAULT ... But for KERN_DEFAULT, there isn't a macro pr_level like pr_devel(). Can anyone show me the correct way? tks -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: question about kref API
On Wed, 23 Jul 2014 17:55:50 -, Jeff Haran said: From: 'Greg KH' [mailto:g...@kroah.com] If you could elaborate on where the race condition is here, I think you'd being doing both me and the community a great service. Nice try with the Do it for the community because I don't understand this! appeal, that doesn't work for me, sorry... Boy, I try to be as deferential as possible here and you come back with this snarky response. My experience is when software developers can't or won't explain how their code works, it's because they don't understand it themselves. On the other hand, the kernel community does expect you to do a large chunk of the learning for yourself - first, because Greg KH isn't a scalable resource, and second, because if you take the time to figure it out for yourself, you'll understand it better than if Greg walked you through it. pgp7AVt3rYMuT.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk or pr_level?
On Wed, Jul 23, 2014 at 02:45:05PM -0700, Arlie Stephens wrote: On Jul 23 2014, Kristofer Hallin wrote: 1. No. Depending on what subsystem your are printing logs from you should use different functions for logging. In the networking subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will always work and is always preferred over printk. Why? No snark intended here, just confused curiousity. It would seem to me that one common method of printing would be better than a different one for each subsystem, each needing to be individually remembered, and potentially having its own bugs\b\b\b\bquirks. The kernel is complex enough, without adding uneeded extra. Yes it is, but it's layered, in that normally you only deal with one specific layer. Very rarely are you touching code everywhere in the kernel. And yes, this begs the question of why you want to print messages from the kernel, whether they ought to be conditional and/or rate limited, etc. etc. Clearly the recommendation of pr_debug() suggests someone thinks they should be at least somewhat conditional... Ok, here's the rule in one sentance: Be as _descriptive_ as you can with the device that is emitting the message. So what does that mean in reality? Use the subsystem's logging macros for your messages. If you are not in a subsystem, then fall back to the default pr_* messages. So, if you are a network driver, then use netdev_dbg(). Other subsystems of class devices have their own form of logging macros, and they should be easy to find. If you aren't in a class driver, but are a driver, then use dev_dbg(), because you do have a device pointer accessable to you (if you don't, either you are in your module init or exit function, and you shouldn't be printing messages then anyway.) If you are not in a driver, and you do not have _any_ 'struct device' accessable to you, reconsider if you really want to be printing anything, as the use of it to a user is going to be really low. But if you have to, then fall back to the pr_* functions, as those tie into the dynamic debugging logic of the kernel, and provide a format that is unified that userspace tools can use to hopefully search and find things properly. So there is a method to this madness, and it is pretty simple if you think about it this way. Does that help out? greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk or pr_level?
On Wed, Jul 23, 2014 at 04:00:04PM -0700, Greg KH wrote: On Wed, Jul 23, 2014 at 02:45:05PM -0700, Arlie Stephens wrote: On Jul 23 2014, Kristofer Hallin wrote: 1. No. Depending on what subsystem your are printing logs from you should use different functions for logging. In the networking subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will always work and is always preferred over printk. Why? No snark intended here, just confused curiousity. It would seem to me that one common method of printing would be better than a different one for each subsystem, each needing to be individually remembered, and potentially having its own bugs\b\b\b\bquirks. The kernel is complex enough, without adding uneeded extra. Yes it is, but it's layered, in that normally you only deal with one specific layer. Very rarely are you touching code everywhere in the kernel. And yes, this begs the question of why you want to print messages from the kernel, whether they ought to be conditional and/or rate limited, etc. etc. Clearly the recommendation of pr_debug() suggests someone thinks they should be at least somewhat conditional... Ok, here's the rule in one sentance: Be as _descriptive_ as you can with the device that is emitting the message. So what does that mean in reality? Use the subsystem's logging macros for your messages. If you are not in a subsystem, then fall back to the default pr_* messages. So, if you are a network driver, then use netdev_dbg(). Other subsystems of class devices have their own form of logging macros, and they should be easy to find. If you aren't in a class driver, but are a driver, then use dev_dbg(), because you do have a device pointer accessable to you (if you don't, either you are in your module init or exit function, and you shouldn't be printing messages then anyway.) If you are not in a driver, and you do not have _any_ 'struct device' accessable to you, reconsider if you really want to be printing anything, as the use of it to a user is going to be really low. But if you have to, then fall back to the pr_* functions, as those tie into the dynamic debugging logic of the kernel, and provide a format that is unified that userspace tools can use to hopefully search and find things properly. Oh, and never use a raw printk() call anymore, someone will just come along behind you and fix it up to use the proper macro, if you happen to get it accepted into the kernel tree. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: printk or pr_level?
Hi guys, Thanks for the help, I learned a lot of new things. On 7/23/14, 8:00 PM, Greg KH wrote: On Wed, Jul 23, 2014 at 04:00:04PM -0700, Greg KH wrote: On Wed, Jul 23, 2014 at 02:45:05PM -0700, Arlie Stephens wrote: On Jul 23 2014, Kristofer Hallin wrote: 1. No. Depending on what subsystem your are printing logs from you should use different functions for logging. In the networking subsystem netdev_dbg is suitable and so on. Otherwise pr_debug will always work and is always preferred over printk. Why? No snark intended here, just confused curiousity. It would seem to me that one common method of printing would be better than a different one for each subsystem, each needing to be individually remembered, and potentially having its own bugs\b\b\b\bquirks. The kernel is complex enough, without adding uneeded extra. Yes it is, but it's layered, in that normally you only deal with one specific layer. Very rarely are you touching code everywhere in the kernel. And yes, this begs the question of why you want to print messages from the kernel, whether they ought to be conditional and/or rate limited, etc. etc. Clearly the recommendation of pr_debug() suggests someone thinks they should be at least somewhat conditional... Ok, here's the rule in one sentance: Be as _descriptive_ as you can with the device that is emitting the message. So what does that mean in reality? Use the subsystem's logging macros for your messages. If you are not in a subsystem, then fall back to the default pr_* messages. So, if you are a network driver, then use netdev_dbg(). Other subsystems of class devices have their own form of logging macros, and they should be easy to find. If you aren't in a class driver, but are a driver, then use dev_dbg(), because you do have a device pointer accessable to you (if you don't, either you are in your module init or exit function, and you shouldn't be printing messages then anyway.) If you are not in a driver, and you do not have _any_ 'struct device' accessable to you, reconsider if you really want to be printing anything, as the use of it to a user is going to be really low. But if you have to, then fall back to the pr_* functions, as those tie into the dynamic debugging logic of the kernel, and provide a format that is unified that userspace tools can use to hopefully search and find things properly. Oh, and never use a raw printk() call anymore, someone will just come along behind you and fix it up to use the proper macro, if you happen to get it accepted into the kernel tree. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Doubt Regarding Floating Point Arithmetic
Can you please explain me one scenario that lets suppose take calculator application in lower level it should interact with kernel code So here who is take care of Floating point calculations? Sorry if i am wrong Thanks for replying me On 23 July 2014 08:45, me storage me.storage...@gmail.com wrote: Hi I am reading LDD .In that i didn't understand one point .In Chapter 2(Building and Running Modules) they mentioned that Kernel code cannot do floating point arithmetic .My doubt is which code is used for floating point arithmetic that means at low level? Thank you ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Doubt Regarding Floating Point Arithmetic
On Thu, Jul 24, 2014 at 08:09:31AM +0530, me storage wrote: Can you please explain me one scenario that lets suppose take calculator application in lower level it should interact with kernel code So here who is take care of Floating point calculations? The userspace program does the floating point calculations. The kernel would not interact with a calculator application in a way that would require the kernel to do anything here, it merely schedules the userspace tasks to run. Hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Help with flame wars
As a new kernel developer I seem to have sent out some bad patches and the other developers are stating I should stop working on the kernel and learn C , even though I known it. I would like to see if we can stop these flame wars as there really wanting me to quit. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Help with flame wars
Could we have a look at this patches?somewhere? On Thu, Jul 24, 2014 at 7:37 AM, Nick Krause xerofo...@gmail.com wrote: As a new kernel developer I seem to have sent out some bad patches and the other developers are stating I should stop working on the kernel and learn C , even though I known it. I would like to see if we can stop these flame wars as there really wanting me to quit. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Help with flame wars
Appeared on LKML two days ago. https://lkml.org/lkml/2014/7/22/737 On 24 Jul 2014 07:04, David kiarie davidkiar...@gmail.com wrote: Could we have a look at this patches?somewhere? On Thu, Jul 24, 2014 at 7:37 AM, Nick Krause xerofo...@gmail.com wrote: As a new kernel developer I seem to have sent out some bad patches and the other developers are stating I should stop working on the kernel and learn C , even though I known it. I would like to see if we can stop these flame wars as there really wanting me to quit. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Help with flame wars
Seems like you got some great guidance too. https://lkml.org/lkml/2014/7/23/443 On 24 Jul 2014 06:38, Nick Krause xerofo...@gmail.com wrote: As a new kernel developer I seem to have sent out some bad patches and the other developers are stating I should stop working on the kernel and learn C , even though I known it. I would like to see if we can stop these flame wars as there really wanting me to quit. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
