On Thu, Sep 04, 2014 at 11:21:18PM +0200, Luis R. Rodriguez wrote:
> I still believe its a good approach if we wanted to scale it but that
> would require the desire to do so, I obviously considered it worthwhile
> as I shaved off at least ~1 second off kernel boot time when doing an
> original pro
On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote:
> On Sun, Aug 31, 2014 at 01:14:07PM -0700, Dmitry Torokhov wrote:
> > On Sun, Aug 31, 2014 at 12:31:40PM -0700, Greg KH wrote:
> > > On Sun, Aug 31, 2014 at 12:24:46PM -0700, Arjan van de Ven wrote:
> > > > >>before we added the current asyn
Hello, Dmitry.
On Sun, Aug 31, 2014 at 04:06:51PM -0700, Dmitry Torokhov wrote:
> On Sun, Aug 31, 2014 at 06:02:38PM -0400, Tejun Heo wrote:
> > Hmmm... that is a different case from the one I'm aware of - userland
> > timing out on module probing and sending SIGKILL aborting device
> > probing, w
Hello,
On Sun, Aug 31, 2014 at 04:20:08PM -0700, Arjan van de Ven wrote:
> >Oh, but there already is a reported case which fails. Hard drives
> >with a lot of platters take > 10secs to spin up and there are
> >configurations which regularly fail the initial reset and it's quite
> >rare but probin
On 8/31/2014 3:53 PM, Tejun Heo wrote:
Hello,
On Sun, Aug 31, 2014 at 03:15:34PM -0700, Greg KH wrote:
For the use cases we have today, it would work. We have a few drivers
that take a _long_ time in their probe callback, and they need to be
made async for various reasons (modprobe timeout kil
On Sun, Aug 31, 2014 at 06:02:38PM -0400, Tejun Heo wrote:
> Hello, Dmitry.
>
> On Sun, Aug 31, 2014 at 11:28:51AM -0700, Dmitry Torokhov wrote:
> > HI Tejun,
> >
> > On Sun, Aug 31, 2014 at 06:13:58AM -0400, Tejun Heo wrote:
> > > I haven't followed the previous discussions so please let me know
Hello, Dmitry.
On Sun, Aug 31, 2014 at 03:51:40PM -0700, Dmitry Torokhov wrote:
> > > Luis, care to redo the patches in this way? It should be a lot simpler
> > > (no messing around with init levels and linker fun...)
> >
> > I don't think binding that switch to the driver is gonna work. This
>
Hello,
On Sun, Aug 31, 2014 at 03:15:34PM -0700, Greg KH wrote:
> For the use cases we have today, it would work. We have a few drivers
> that take a _long_ time in their probe callback, and they need to be
> made async for various reasons (modprobe timeout killer, touchscreen
> init sequence sta
On Sun, Aug 31, 2014 at 05:53:13PM -0400, Tejun Heo wrote:
> Hello, Greg.
>
> On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote:
> > > Right, all (well almost all) I wanted is for individual drivers to declare
> > > their probe() functions asynchronous and driver core scheduling async
> > >
On 8/31/2014 3:45 PM, Dmitry Torokhov wrote:
On August 31, 2014 3:32:19 PM PDT, Arjan van de Ven
wrote:
On 8/31/2014 1:06 PM, 吴章金 wrote:
Hi, folks
I'm back to this discussion,
The original requirement of my first RFC patchset is mainly for
Android Smartphone use case:
1. We want light on
On August 31, 2014 3:32:19 PM PDT, Arjan van de Ven
wrote:
>On 8/31/2014 1:06 PM, 吴章金 wrote:
>> Hi, folks
>>
>> I'm back to this discussion,
>>
>> The original requirement of my first RFC patchset is mainly for
>Android Smartphone use case:
>>
>> 1. We want light on LCD and draw a logo immediatel
On 8/31/2014 1:06 PM, 吴章金 wrote:
Hi, folks
I'm back to this discussion,
The original requirement of my first RFC patchset is mainly for Android
Smartphone use case:
1. We want light on LCD and draw a logo immediately after power key press(don't
consider uboot or lk biotloader here).
2. We wa
On Sun, Aug 31, 2014 at 05:53:13PM -0400, Tejun Heo wrote:
> Hello, Greg.
>
> On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote:
> > > Right, all (well almost all) I wanted is for individual drivers to declare
> > > their probe() functions asynchronous and driver core scheduling async
> > >
Hello, Dmitry.
On Sun, Aug 31, 2014 at 11:28:51AM -0700, Dmitry Torokhov wrote:
> HI Tejun,
>
> On Sun, Aug 31, 2014 at 06:13:58AM -0400, Tejun Heo wrote:
> > I haven't followed the previous discussions so please let me know if
> > this has been discussed before. It looks like you're trying to e
Hello, Greg.
On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote:
> > Right, all (well almost all) I wanted is for individual drivers to declare
> > their probe() functions asynchronous and driver core scheduling async attach
> > and properly handle failures from it.
>
> Yes, that's what I wa
On Sun, Aug 31, 2014 at 01:14:07PM -0700, Dmitry Torokhov wrote:
> On Sun, Aug 31, 2014 at 12:31:40PM -0700, Greg KH wrote:
> > On Sun, Aug 31, 2014 at 12:24:46PM -0700, Arjan van de Ven wrote:
> > > >>before we added the current async approach the approach of async init
> > > >>calls was tried
>
On Sun, Aug 31, 2014 at 12:31:40PM -0700, Greg KH wrote:
> On Sun, Aug 31, 2014 at 12:24:46PM -0700, Arjan van de Ven wrote:
> > >>before we added the current async approach the approach of async init
> > >>calls was tried
> > >>At the time, Linus hated it and he was right, it was not the right th
On Sun, Aug 31, 2014 at 12:26:06PM -0700, Arjan van de Ven wrote:
> On 8/31/2014 10:52 AM, Dmitry Torokhov wrote:
> >On Sun, Aug 31, 2014 at 07:05:26AM -0400, Tejun Heo wrote:
> >>On Sun, Aug 31, 2014 at 07:02:00AM -0400, Tejun Heo wrote:
> >>>So, something like the following. A couple things to n
On Sun, Aug 31, 2014 at 12:24:46PM -0700, Arjan van de Ven wrote:
> >>before we added the current async approach the approach of async init calls
> >>was tried
> >>At the time, Linus hated it and he was right, it was not the right thing.
> >>
> >>What is different this time to make this the right
On 8/31/2014 10:52 AM, Dmitry Torokhov wrote:
On Sun, Aug 31, 2014 at 07:05:26AM -0400, Tejun Heo wrote:
On Sun, Aug 31, 2014 at 07:02:00AM -0400, Tejun Heo wrote:
So, something like the following. A couple things to note
* driver_attach() can never fail but is marked with __must_check. We
before we added the current async approach the approach of async init calls was
tried
At the time, Linus hated it and he was right, it was not the right thing.
What is different this time to make this the right thing to do ?
Because otherwise drivers still have to do this, but open code it. Le
HI Tejun,
On Sun, Aug 31, 2014 at 06:13:58AM -0400, Tejun Heo wrote:
> Hello, Luis.
>
> I haven't followed the previous discussions so please let me know if
> this has been discussed before. It looks like you're trying to extend
> the async mechanism and applying them to init functions themselve
On Sun, Aug 31, 2014 at 07:05:26AM -0400, Tejun Heo wrote:
> On Sun, Aug 31, 2014 at 07:02:00AM -0400, Tejun Heo wrote:
> > So, something like the following. A couple things to note
> >
> > * driver_attach() can never fail but is marked with __must_check. We
> > prolly should change it to void
On Sun, Aug 31, 2014 at 07:44:02AM -0700, Arjan van de Ven wrote:
> On 8/31/2014 2:03 AM, Luis R. Rodriguez wrote:
> >From: "Luis R. Rodriguez"
> >
> >While reviewing Wu Zhangjin's solution to async probe [0] and his
> >ideas on creating async groups I decided to try following the init
> >levels o
On Sun, Aug 31, 2014 at 02:03:17AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> While reviewing Wu Zhangjin's solution to async probe [0] and his
> ideas on creating async groups I decided to try following the init
> levels on the kernel to try to help with synchronization at l
On 8/31/2014 2:03 AM, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
While reviewing Wu Zhangjin's solution to async probe [0] and his
ideas on creating async groups I decided to try following the init
levels on the kernel to try to help with synchronization at least
on some level. This bor
(cc'ing Rusty for module loading)
Hello,
On Sun, Aug 31, 2014 at 01:25:03PM +0200, David Herrmann wrote:
> On Sun, Aug 31, 2014 at 1:02 PM, Tejun Heo wrote:
> > @@ -689,9 +704,23 @@ int bus_add_driver(struct device_driver *drv)
> >
> > klist_add_tail(&priv->knode_bus, &bus->p->klist_driv
Hi
On Sun, Aug 31, 2014 at 1:02 PM, Tejun Heo wrote:
> So, something like the following. A couple things to note
>
> * driver_attach() can never fail but is marked with __must_check. We
> prolly should change it to void.
>
> * Old/weird userspace which depends on insmod to wait for device
>
On Sun, Aug 31, 2014 at 07:02:00AM -0400, Tejun Heo wrote:
> So, something like the following. A couple things to note
>
> * driver_attach() can never fail but is marked with __must_check. We
> prolly should change it to void.
>
> * Old/weird userspace which depends on insmod to wait for devi
So, something like the following. A couple things to note
* driver_attach() can never fail but is marked with __must_check. We
prolly should change it to void.
* Old/weird userspace which depends on insmod to wait for device
probing might choke and the new behavior might need to be switched
Hello, Luis.
I haven't followed the previous discussions so please let me know if
this has been discussed before. It looks like you're trying to extend
the async mechanism and applying them to init functions themselves.
That sounds kinda weird to me. Isn't the root cause of the problem
doing dev
From: "Luis R. Rodriguez"
While reviewing Wu Zhangjin's solution to async probe [0] and his
ideas on creating async groups I decided to try following the init
levels on the kernel to try to help with synchronization at least
on some level. This borrows ideas discussed with the kthread_create()
so
32 matches
Mail list logo
