+ LKML
---------- Forwarded message ----------
From: Arend van Spriel <[email protected]>
Date: Tue, Jan 9, 2018 at 8:19 PM
Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump
To: Greg Kroah-Hartman <[email protected]>
On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote:
>> From: Arend van Spriel <[email protected]>
>>
>> Since commit 833c95456a70 ("device coredump: add new device coredump class")
>> device drivers have a unified way to provide binary data obtained from a
>> failing_device to user-space. However, there may be use-cases in which the
>> driver has no reason to obtain the data, but user-space wants to initiate
>> it. This adds a coredump device attribute in sysfs when the driver bound to
>> the device supports the newly added coredump driver callback.
>
> What driver is going to set this? I don't want to add new options to
> the kernel that never get used, do you have a driver to use it?
Hi Greg,
After sending these patches I realized that was going to be your
response, but decided to wait for it. Obviously there is a driver for
which I would like to have an option to create a device coredump from
user-space, ie. the brcm80211 drivers (maintained by my alter-ego ;-)
). I can post these patches again as RFC including the brcm80211
driver patches. Here a bit of background about this itch. A couple of
other driver support their own coredump implementation, ie. not using
dev_coredump class and some support user-space initiated coredump
through debugfs. As that depends on a Kconfig option I looked for
other solutions. At first I considered doing it in dev_coredump class
itself by doing:
# echo 0000:04:00.0 > /sys/class/devcoredump/trigger
with 'trigger' being a new sysfs attribute for devcoredump. However,
using the driver core turned out to be much simpler, but I am still
open for other/better options.
Regards,
Arend
On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote:
> + LKML
>
> ---------- Forwarded message ----------
> From: Arend van Spriel <[email protected]>
> Date: Tue, Jan 9, 2018 at 8:19 PM
> Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump
> To: Greg Kroah-Hartman <[email protected]>
>
>
> On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote:
> >> From: Arend van Spriel <[email protected]>
> >>
> >> Since commit 833c95456a70 ("device coredump: add new device coredump class")
> >> device drivers have a unified way to provide binary data obtained from a
> >> failing_device to user-space. However, there may be use-cases in which the
> >> driver has no reason to obtain the data, but user-space wants to initiate
> >> it. This adds a coredump device attribute in sysfs when the driver bound to
> >> the device supports the newly added coredump driver callback.
> >
> > What driver is going to set this? I don't want to add new options to
> > the kernel that never get used, do you have a driver to use it?
>
> Hi Greg,
>
> After sending these patches I realized that was going to be your
> response, but decided to wait for it. Obviously there is a driver for
> which I would like to have an option to create a device coredump from
> user-space, ie. the brcm80211 drivers (maintained by my alter-ego ;-)
> ). I can post these patches again as RFC including the brcm80211
> driver patches. Here a bit of background about this itch. A couple of
> other driver support their own coredump implementation, ie. not using
> dev_coredump class and some support user-space initiated coredump
> through debugfs. As that depends on a Kconfig option I looked for
> other solutions. At first I considered doing it in dev_coredump class
> itself by doing:
>
> # echo 0000:04:00.0 > /sys/class/devcoredump/trigger
>
> with 'trigger' being a new sysfs attribute for devcoredump. However,
> using the driver core turned out to be much simpler, but I am still
> open for other/better options.
Nah, I don't object to the patches, but I want someone to use it. So
can you resend these, with a RFC for the driver you want using it as the
last patch?
thanks,
greg k-h
On Tue, Jan 9, 2018 at 9:03 PM, Greg KH <[email protected]> wrote:
> On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote:
>> + LKML
>>
>> ---------- Forwarded message ----------
>> From: Arend van Spriel <[email protected]>
>> Date: Tue, Jan 9, 2018 at 8:19 PM
>> Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump
>> To: Greg Kroah-Hartman <[email protected]>
>>
>>
>> On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>> > On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote:
>> >> From: Arend van Spriel <[email protected]>
>> >>
>> >> Since commit 833c95456a70 ("device coredump: add new device coredump class")
>> >> device drivers have a unified way to provide binary data obtained from a
>> >> failing_device to user-space. However, there may be use-cases in which the
>> >> driver has no reason to obtain the data, but user-space wants to initiate
>> >> it. This adds a coredump device attribute in sysfs when the driver bound to
>> >> the device supports the newly added coredump driver callback.
>> >
>> > What driver is going to set this? I don't want to add new options to
>> > the kernel that never get used, do you have a driver to use it?
>>
>> Hi Greg,
>>
>> After sending these patches I realized that was going to be your
>> response, but decided to wait for it. Obviously there is a driver for
>> which I would like to have an option to create a device coredump from
>> user-space, ie. the brcm80211 drivers (maintained by my alter-ego ;-)
>> ). I can post these patches again as RFC including the brcm80211
>> driver patches. Here a bit of background about this itch. A couple of
>> other driver support their own coredump implementation, ie. not using
>> dev_coredump class and some support user-space initiated coredump
>> through debugfs. As that depends on a Kconfig option I looked for
>> other solutions. At first I considered doing it in dev_coredump class
>> itself by doing:
>>
>> # echo 0000:04:00.0 > /sys/class/devcoredump/trigger
>>
>> with 'trigger' being a new sysfs attribute for devcoredump. However,
>> using the driver core turned out to be much simpler, but I am still
>> open for other/better options.
>
> Nah, I don't object to the patches, but I want someone to use it. So
> can you resend these, with a RFC for the driver you want using it as the
> last patch?
Thanks. Will do that. FWIW, there are a couple more drivers that I
would like to change to using this as well.
Regards,
Arend
On Tue, Jan 09, 2018 at 09:06:21PM +0100, Arend van Spriel wrote:
> On Tue, Jan 9, 2018 at 9:03 PM, Greg KH <[email protected]> wrote:
> > On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote:
> >> + LKML
> >>
> >> ---------- Forwarded message ----------
> >> From: Arend van Spriel <[email protected]>
> >> Date: Tue, Jan 9, 2018 at 8:19 PM
> >> Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump
> >> To: Greg Kroah-Hartman <[email protected]>
> >>
> >>
> >> On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman
> >> <[email protected]> wrote:
> >> > On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote:
> >> >> From: Arend van Spriel <[email protected]>
> >> >>
> >> >> Since commit 833c95456a70 ("device coredump: add new device coredump class")
> >> >> device drivers have a unified way to provide binary data obtained from a
> >> >> failing_device to user-space. However, there may be use-cases in which the
> >> >> driver has no reason to obtain the data, but user-space wants to initiate
> >> >> it. This adds a coredump device attribute in sysfs when the driver bound to
> >> >> the device supports the newly added coredump driver callback.
> >> >
> >> > What driver is going to set this? I don't want to add new options to
> >> > the kernel that never get used, do you have a driver to use it?
> >>
> >> Hi Greg,
> >>
> >> After sending these patches I realized that was going to be your
> >> response, but decided to wait for it. Obviously there is a driver for
> >> which I would like to have an option to create a device coredump from
> >> user-space, ie. the brcm80211 drivers (maintained by my alter-ego ;-)
> >> ). I can post these patches again as RFC including the brcm80211
> >> driver patches. Here a bit of background about this itch. A couple of
> >> other driver support their own coredump implementation, ie. not using
> >> dev_coredump class and some support user-space initiated coredump
> >> through debugfs. As that depends on a Kconfig option I looked for
> >> other solutions. At first I considered doing it in dev_coredump class
> >> itself by doing:
> >>
> >> # echo 0000:04:00.0 > /sys/class/devcoredump/trigger
> >>
> >> with 'trigger' being a new sysfs attribute for devcoredump. However,
> >> using the driver core turned out to be much simpler, but I am still
> >> open for other/better options.
> >
> > Nah, I don't object to the patches, but I want someone to use it. So
> > can you resend these, with a RFC for the driver you want using it as the
> > last patch?
>
> Thanks. Will do that. FWIW, there are a couple more drivers that I
> would like to change to using this as well.
Great, do it for all of them!