lkml.org 
[lkml]   [2014]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
    On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote:
    > On Sun, Sep 28, 2014 at 11:03:29AM -0400, Tejun Heo wrote:
    > > Hello,
    > >
    > > On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
    > > ...
    > > > Systemd should consider enabling async probe on device drivers
    > > > it loads through systemd-udev but probably does not want to
    > > > enable it for modules loaded through systemd-modules-load
    > > > (modules-load.d). At least on my booting enablign async probe
    > > > for all modules fails to boot as such in order to make this
    > >
    > > Did you find out why boot failed with those modules?
    >
    > No, it seems this was early in boot and I haven't been able to capture the logs
    > yet of the faults. More on this below.
    >
    > > > a bit more useful we whitelist a few buses where it should be
    > > > at least in theory safe to try to enable async probe. This
    > > > way even if systemd tried to ask to enable async probe for all
    > > > its device drivers the kernel won't blindly do this. We also
    > > > have the sync_probe flag which device drivers can themselves
    > > > enable *iff* its known the device driver should never async
    > > > probe.
    > > >
    > > > In order to help *test* things folks can use the bus.safe_mod_async_probe=1
    > > > kernel parameter which will work as if userspace would have
    > > > requested all modules to load with async probe. Daring folks can
    > > > also use bus.force_mod_async_probe=1 which will enable asynch probe
    > > > even on buses not tested in any way yet, if you use that though
    > > > you're on your own.
    > >
    > > If those two knobs are meant for debugging, let's please make that
    > > fact immediately evident. e.g. Make them ugly boot params like
    > > "__DEVEL__driver_force_mod_async_probe". Devel/debug options ending
    > > up becoming stable interface are really nasty.
    >
    > Sure make sense, I wasn't quite sure how to make this quite clear,
    > a naming convention seems good to me but I also had added at least
    > a print about this on the log. Ideally I think a TAIN_DEBUG would
    > be best and it seems it could be useful for many other cases in
    > the kernel, we could also just re-use TAINT_CRAP as well. Thoughts?
    > Greg?

    TAINT_CRAP is for drivers/staging/ code, don't try to repurpose it for
    some other horrid option. There's no reason we can't add more taint
    flags for this.

    greg k-h


    \
     
     \ /
      Last update: 2014-09-30 00:21    [W:3.138 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site