All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com ('Greg KH')
To: kernelnewbies@lists.kernelnewbies.org
Subject: question about kref API
Date: Wed, 23 Jul 2014 11:32:27 -0700	[thread overview]
Message-ID: <20140723183227.GE16664@kroah.com> (raw)
In-Reply-To: <4E5779AD88B2F040B8A7E83ECF544D1A533A75@SJCPEX01CL02.citrite.net>

On Wed, Jul 23, 2014 at 05:55:50PM +0000, Jeff Haran wrote:
> > -----Original Message-----
> > From: 'Greg KH' [mailto:greg at kroah.com]
> > Sent: Wednesday, July 23, 2014 10:48 AM
> > To: Jeff Haran
> > Cc: kernelnewbies at kernelnewbies.org
> > 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.

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

  reply	other threads:[~2014-07-23 18:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22  0:27 question about kref API Jeff Haran
2014-07-22  2:18 ` Greg KH
2014-07-22 17:25   ` Jeff Haran
2014-07-22 23:47     ` Greg KH
2014-07-23 17:33       ` Jeff Haran
2014-07-23 17:38         ` Jeff Haran
2014-07-23 17:48         ` 'Greg KH'
2014-07-23 17:55           ` Jeff Haran
2014-07-23 18:32             ` 'Greg KH' [this message]
2014-07-23 21:45             ` Valdis.Kletnieks at vt.edu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140723183227.GE16664@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.