RE: question about kref API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: 'Greg KH' [mailto:greg@xxxxxxxxx]
> Sent: Wednesday, July 23, 2014 10:48 AM
> To: Jeff Haran
> Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
> Subject: Re: question about kref API
> 
> On Wed, Jul 23, 2014 at 05:33:19PM +0000, 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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux