From: enjoymindful@gmail.com (Real Name)
To: kernelnewbies@lists.kernelnewbies.org
Subject: EPROBE_DEFER and how it is supposed to work
Date: Wed, 10 Sep 2014 11:08:45 +0800 [thread overview]
Message-ID: <20140910030845.GA9846@name.redhat.com> (raw)
In-Reply-To: <fdb8424613e9495987c7103006c460e9@DM2PR05MB671.namprd05.prod.outlook.com>
On Tue, Sep 09, 2014 at 06:26:27PM +0000, Rajat Jain wrote:
> Hi,
>
> I'm not a newbie, but I am trying to understand the semantics of deferred probing.
>
> My question is generic, but for an example:
>
> Let's say I have a platform driver "A" for a device "a", that requires device "b" (controlled by driver "B") to be operational first. Both A &B can be built as part of kernel, or as modules independently. As far as I could tell, there is no way to specify the ORDER in which the drivers' probe routines should be called. I took a look at modprobe / depmod, but it seems to be of relevance for modules only that are loaded from user space. My questions:
>
> 1) Is there a way to specify that "Kernel should call A's probe routine only after B's probe routine"?
You can ask module A to load the required module B.
For example, lib/textsearch.c:textsearch_prepare -> lookup_ts_algo
lookup_ts_algo will load ts_bm.ko/ts_fsm.ko/ts_kmp.ko as required.
>
> 2) How I currently do this: In A's probe routine, I currently check if the device "b" is available. If not, I return -EPROBE_DEFER. This mostly works ok. However, I'm curious about the case where the driver B is not built as part of the kernel but A is. After getting an _EPROB_DEFER from a B's probe routine, when will the kernel try again? And for how long would it keep on trying? I verified that if I load the driver B manually from user space, the A's probe routine does not get called (if it gets called now - it would have returned success!).
>
> Thanks,
>
> Rajat
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
WARNING: multiple messages have this Message-ID (diff)
From: Real Name <enjoymindful@gmail.com>
To: Rajat Jain <rajatjain@juniper.net>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>,
"linux-newbie@vger.kernel.org" <linux-newbie@vger.kernel.org>
Subject: Re: EPROBE_DEFER and how it is supposed to work
Date: Wed, 10 Sep 2014 11:08:45 +0800 [thread overview]
Message-ID: <20140910030845.GA9846@name.redhat.com> (raw)
In-Reply-To: <fdb8424613e9495987c7103006c460e9@DM2PR05MB671.namprd05.prod.outlook.com>
On Tue, Sep 09, 2014 at 06:26:27PM +0000, Rajat Jain wrote:
> Hi,
>
> I'm not a newbie, but I am trying to understand the semantics of deferred probing.
>
> My question is generic, but for an example:
>
> Let's say I have a platform driver "A" for a device "a", that requires device "b" (controlled by driver "B") to be operational first. Both A &B can be built as part of kernel, or as modules independently. As far as I could tell, there is no way to specify the ORDER in which the drivers' probe routines should be called. I took a look at modprobe / depmod, but it seems to be of relevance for modules only that are loaded from user space. My questions:
>
> 1) Is there a way to specify that "Kernel should call A's probe routine only after B's probe routine"?
You can ask module A to load the required module B.
For example, lib/textsearch.c:textsearch_prepare -> lookup_ts_algo
lookup_ts_algo will load ts_bm.ko/ts_fsm.ko/ts_kmp.ko as required.
>
> 2) How I currently do this: In A's probe routine, I currently check if the device "b" is available. If not, I return -EPROBE_DEFER. This mostly works ok. However, I'm curious about the case where the driver B is not built as part of the kernel but A is. After getting an _EPROB_DEFER from a B's probe routine, when will the kernel try again? And for how long would it keep on trying? I verified that if I load the driver B manually from user space, the A's probe routine does not get called (if it gets called now - it would have returned success!).
>
> Thanks,
>
> Rajat
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
next prev parent reply other threads:[~2014-09-10 3:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 18:26 EPROBE_DEFER and how it is supposed to work Rajat Jain
2014-09-09 18:26 ` Rajat Jain
2014-09-10 3:08 ` Real Name [this message]
2014-09-10 3:08 ` Real Name
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=20140910030845.GA9846@name.redhat.com \
--to=enjoymindful@gmail.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.