All of lore.kernel.org
 help / color / mirror / Atom feed
From: sagi@grimberg.me (Sagi Grimberg)
Subject: [PATCH] nvme: allow lightnvm to have visibility over AER events
Date: Mon, 16 Apr 2018 12:16:50 +0300	[thread overview]
Message-ID: <4b476a76-dccb-7d90-fa79-7e8c425d4f1a@grimberg.me> (raw)
In-Reply-To: <28761F08-1AB9-41FD-BFE2-BBC9779432DA@javigon.com>

Javier,

>> We currently do have some logic in the core to say which events are
>> sent to user space for handling and others that are handled internally.
>> There's currently just two events with kernel specifc handling:
>> namespace inventory change, and firmware activation.
>>
>> The example in your patch looks like one of the scenarios envisioned
>> to be handled by a udev rule. Is that not going to work for you here?
>>
>> If you do have an event that needs special handling, I think you'd want
>> to filter that out of the user space notification and invoke the kernel
>> callback specific to it your event.
> 
> Can I plug a udev rule to an in-kernel driver? A concrete example of the
> events we will handle is pblk having to remap data from a chunk that is
> becoming unreliable.

You can plug user-space action and kernel interface for it. It looks
pretty stateless..

Does pblk expose a char device? I think that user-space can issue
the log page and then pass the information to the kernel..

Given that I do see also that nvmet would be a potential consumer for
AER, maybe user-space would be a good place to handle all this...

  reply	other threads:[~2018-04-16  9:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 11:42 [RFC PATCH] nvme: allow to handle AER events by kernel drivers Javier González
2018-04-13 11:43 ` [PATCH] nvme: allow lightnvm to have visibility over AER events Javier González
2018-04-13 15:27   ` Scott Bauer
2018-04-13 18:01     ` Javier Gonzalez
2018-04-13 16:58   ` Keith Busch
2018-04-13 17:55     ` Javier González
2018-04-16  9:16       ` Sagi Grimberg [this message]
2018-04-16  9:21         ` Javier González
2018-04-13 17:11   ` Christoph Hellwig
2018-04-13 17:20     ` Javier Gonzalez

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=4b476a76-dccb-7d90-fa79-7e8c425d4f1a@grimberg.me \
    --to=sagi@grimberg.me \
    /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.