All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ming Lei <tom.leiming@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Consult] Why need we call device_remove_file() firstly before call device_unregister() ?
Date: Mon, 20 May 2013 10:42:48 +0800	[thread overview]
Message-ID: <51998DA8.70609@asianux.com> (raw)
In-Reply-To: <20130520022016.GA2945@kroah.com>

On 05/20/2013 10:20 AM, Greg Kroah-Hartman wrote:
> On Mon, May 20, 2013 at 10:12:41AM +0800, Chen Gang wrote:
>> > I mean that if no reply by any other members within a week, I will know
>> > it is correct that "we need not call device_remove_file() firstly before
>> > call device_unregister()" (at least, one member's reply supports this
>> > conclusion).
>> > 
>> > I find this 'question' when discussing a patch with another members in
>> > linux-kernel@vger.kernel.org, I have read the related code and also have
>> > searched with google, but can not find the result, so I want to consult
>> > it in linux-kernel@vger.kernel.org.
> Asking random questions on lkml, and relying on the fact that no one
> else happens to say anything, is not any judge as to if the answer is
> correct at all.
> 

OK, I can understand, now, thank you for your reply.

And I wish, we can provide the confirmation of all related questions
about Linux kernel, in the future,


> In fact, just asking questions on lkml has a very low chance of ever
> getting a correct answer, given that the people that usually do know the
> answer to these types of things are usually:
>   1) not reading lkml because they are busy doing real work

I should understand, they have no duty to have to reply the related
mail, especially every members already have their own work (and
normally, they are really busy).


>   2) annoyed by questions that are easily answered by themselves by
>      either:
>        a) reading the code

I have done, so I need not worry about this item. :-)

>        b) writing a simple example module and testing it out yourself
> 

Precisely, I did not do it firstly. It seems I should do it firstly
(although, at least now, I do not think it will get any valuable result
for our this case)

> 
> Good luck,
> 

OK, 'Lucky' is really the first important !!

I should continue to analyze this question, independent this 'consult' mail.


Thanks.
-- 
Chen Gang

Asianux Corporation

      reply	other threads:[~2013-05-20  2:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17  5:43 [Consult] Why need we call device_remove_file() firstly before call device_unregister() ? Chen Gang
2013-05-18 11:06 ` Ming Lei
2013-05-20  1:03   ` Chen Gang
2013-05-20  1:45     ` Greg Kroah-Hartman
2013-05-20  2:12       ` Chen Gang
2013-05-20  2:20         ` Greg Kroah-Hartman
2013-05-20  2:42           ` Chen Gang [this message]

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=51998DA8.70609@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tom.leiming@gmail.com \
    /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.