Hello Linus,
Apologies for the late PULL request.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
This series contains HCH's changes to absorb configfs attribute ->show()
+ ->store() function pointer usage from it's original tree-wide
consumers, into common configfs code.
It includes usb-gadget, target w/ drivers, netconsole and ocfs2 changes
to realize the improved simplicity, that now renders the original
include/target/configfs_macros.h CPP magic for fabric drivers and
others, unnecessary and obsolete.
And with common code in place, new configfs attributes can be added
easier than ever before.
Note, there are further improvements in-flight from other folks for v4.5
code in configfs land, plus number of target fixes for post -rc1 code.
Thank you,
--nab
Christoph Hellwig (23):
configfs: add show and store methods to struct configfs_attribute
usb-gadget: use per-attribute show and store methods
usb-gadget/uvc: use per-attribute show and store methods
usb-gadget/f_hid: use per-attribute show and store methods
usb-gadget/f_acm: use per-attribute show and store methods
usb-gadget/ether: use per-attribute show and store methods
usb-gadget/f_loopback: use per-attribute show and store methods
usb-gadget/f_midi: use per-attribute show and store methods
usb-gadget/f_printer: use per-attribute show and store methods
usb-gadget/f_sourcesink: use per-attribute show and store methods
usb-gadget/f_mass_storage: use per-attribute show and store methods
usb-gadget/f_uac1: use per-attribute show and store methods
usb-gadget/f_uac2: use per-attribute show and store methods
usb-gadget/f_obex: use per-attribute show and store methods
usb-gadget/f_phonet: use per-attribute show and store methods
usb-gadget/f_serial: use per-attribute show and store methods
dlm: use per-attribute show and store methods
spear13xx_pcie_gadget: use per-attribute show and store methods
target: use per-attribute show and store methods
netconsole: use per-attribute show and store methods
ocfs2/cluster: move locking into attribute store methods
ocfs2/cluster: use per-attribute show and store methods
configfs: remove old API
Documentation/filesystems/Makefile | 2 -
Documentation/filesystems/configfs/Makefile | 3 -
Documentation/filesystems/configfs/configfs.txt | 38 +-
.../configfs/configfs_example_explicit.c | 483 --------
Documentation/target/tcm_mod_builder.py | 17 -
drivers/infiniband/ulp/srpt/ib_srpt.c | 78 +-
drivers/misc/spear13xx_pcie_gadget.c | 216 ++--
drivers/net/netconsole.c | 271 +++--
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 153 +--
drivers/target/iscsi/iscsi_target_configfs.c | 791 +++++--------
drivers/target/iscsi/iscsi_target_stat.c | 666 +++++------
drivers/target/loopback/tcm_loop.c | 60 +-
drivers/target/sbp/sbp_target.c | 87 +-
drivers/target/target_core_configfs.c | 1209 +++++++-------------
drivers/target/target_core_fabric_configfs.c | 275 ++---
drivers/target/target_core_internal.h | 3 +
drivers/target/target_core_stat.c | 918 ++++++---------
drivers/target/tcm_fc/tfc_cmd.c | 1 -
drivers/target/tcm_fc/tfc_conf.c | 44 +-
drivers/target/tcm_fc/tfc_io.c | 1 -
drivers/target/tcm_fc/tfc_sess.c | 1 -
drivers/usb/gadget/configfs.c | 295 ++---
drivers/usb/gadget/function/f_acm.c | 26 +-
drivers/usb/gadget/function/f_ecm.c | 8 +-
drivers/usb/gadget/function/f_eem.c | 8 +-
drivers/usb/gadget/function/f_hid.c | 34 +-
drivers/usb/gadget/function/f_loopback.c | 31 +-
drivers/usb/gadget/function/f_mass_storage.c | 119 +-
drivers/usb/gadget/function/f_midi.c | 37 +-
drivers/usb/gadget/function/f_ncm.c | 8 +-
drivers/usb/gadget/function/f_obex.c | 26 +-
drivers/usb/gadget/function/f_phonet.c | 25 +-
drivers/usb/gadget/function/f_printer.c | 30 +-
drivers/usb/gadget/function/f_rndis.c | 8 +-
drivers/usb/gadget/function/f_serial.c | 26 +-
drivers/usb/gadget/function/f_sourcesink.c | 83 +-
drivers/usb/gadget/function/f_subset.c | 8 +-
drivers/usb/gadget/function/f_uac1.c | 39 +-
drivers/usb/gadget/function/f_uac2.c | 28 +-
drivers/usb/gadget/function/u_ether_configfs.h | 44 +-
drivers/usb/gadget/function/uvc_configfs.c | 387 +++----
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 44 +-
drivers/vhost/scsi.c | 41 +-
drivers/xen/xen-scsiback.c | 32 +-
fs/configfs/file.c | 12 +-
fs/dlm/config.c | 288 ++---
fs/ocfs2/cluster/heartbeat.c | 205 +---
fs/ocfs2/cluster/nodemanager.c | 281 ++---
include/linux/configfs.h | 97 +-
include/linux/usb/gadget_configfs.h | 19 +-
include/target/configfs_macros.h | 147 ---
include/target/target_core_base.h | 60 +
include/target/target_core_fabric_configfs.h | 122 --
samples/Kconfig | 6 +
samples/Makefile | 3 +-
samples/configfs/Makefile | 2 +
.../configfs/configfs_sample.c | 140 +--
57 files changed, 2652 insertions(+), 5434 deletions(-)
delete mode 100644 Documentation/filesystems/configfs/Makefile
delete mode 100644 Documentation/filesystems/configfs/configfs_example_explicit.c
delete mode 100644 include/target/configfs_macros.h
delete mode 100644 include/target/target_core_fabric_configfs.h
create mode 100644 samples/configfs/Makefile
rename Documentation/filesystems/configfs/configfs_example_macros.c => samples/configfs/configfs_sample.c (74%)
On Fri, Nov 13, 2015 at 1:59 AM, Nicholas A. Bellinger
<[email protected]> wrote:
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
Ok, not only was this pull request late, it had a semantic conflict
that causes the end result to not compile.
You must have known about that conflict, since it was reported for
linux-next. Alexander Shishkin had a patch for it.
This is the kind of thing you should talk about in your pull request.
Yes, I find these things out. Yes, I can fix it up myself. But the
whole point of linux-next is finding these things and making the
parties aware of it.
If you don't then use the linux-next information when you send my pull
request, exactly *what* was the point of it ever being in linux-next
in the first place?
I'm annoyed. This is not the kind of sh*t I want to deal with on the
Friday before the merge window closes.
I've unpulled it for now. And I'm not sure I want to pull it later
when I'm less annoyed.
So just to make it really clear to people: if you ignore the reports
from linux-next, then I will damn well ignore you. Comprende? Fair is
fair.
Linus
On Fri, 2015-11-13 at 09:48 -0800, Linus Torvalds wrote:
> On Fri, Nov 13, 2015 at 1:59 AM, Nicholas A. Bellinger
> <[email protected]> wrote:
> >
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
>
> Ok, not only was this pull request late, it had a semantic conflict
> that causes the end result to not compile.
>
> You must have known about that conflict, since it was reported for
> linux-next. Alexander Shishkin had a patch for it.
>
> This is the kind of thing you should talk about in your pull request.
> Yes, I find these things out. Yes, I can fix it up myself. But the
> whole point of linux-next is finding these things and making the
> parties aware of it.
>
> If you don't then use the linux-next information when you send my pull
> request, exactly *what* was the point of it ever being in linux-next
> in the first place?
Ugh.
>
> I'm annoyed. This is not the kind of sh*t I want to deal with on the
> Friday before the merge window closes.
>
> I've unpulled it for now. And I'm not sure I want to pull it later
> when I'm less annoyed.
>
> So just to make it really clear to people: if you ignore the reports
> from linux-next, then I will damn well ignore you. Comprende? Fair is
> fair.
Would you accept an updated PULL request with Alexander's patch, or
prefer this whole series wait until v4.5..?
Certainly it's my fault for not getting it sent out earlier, but the
patches themselves, minus Alexander's extra hwtracing fix-up, have seen
enough review + build testing to be uncontroversial at this point.
--nab
On Fri, Nov 13, 2015 at 11:55 AM, Nicholas A. Bellinger
<[email protected]> wrote:
>
>> So just to make it really clear to people: if you ignore the reports
>> from linux-next, then I will damn well ignore you. Comprende? Fair is
>> fair.
>
> Would you accept an updated PULL request with Alexander's patch, or
> prefer this whole series wait until v4.5..?
You can't just apply Alexander's patch, because that patch wouldn't
compile in your tree - it comes about as a conflict due to me having
gotten commit 7bd1d4093c2f ("stm class: Introduce an abstraction for
System Trace Module devices") from one of Greg's pulls.
But what I want maintainers to do is to *tell* be about these things.
I have absolutely no issues with handling merge conflicts - they
happen all the time.
But when those merge conflicts were known about from linux-next, and
particularly when those merge conflicts were silent semantic conflicts
that didn't even show up as an actual explicit conflict int he git
history (only as a compile issue - or worse - a runtime problem), then
I want maintainers to
(a) show they were aware of it (you should have been, or there is
something wrong in our process)
and
(b) let me know about it and point to the resolution.
That way I'm not taken by surprise, and things won't fall through the cracks.
Yes, I do allmodconfig builds between every pull, which is how I
noticed this, but that doesn't always catch things either, and it
doesn't catch _other_ configs that may be relevant too.
Note that it also doesn't mean that I want you to do the merge for me.
I want to be aware of these issues, and I want to see the resolution,
and I'm more than happy to do it myself. In fact, I almost insist,
unless the resolution is _so_ painful that I push it back to the
maintainer. I just want the heads-up about the issue and about the fix
for the issue, because that is the upside of linux-next: these things
gets noticed there first, exactly so that people can be aware of them.
And yes, I also react a lot more negatively when things like this
happen with the very end of the merge window in sight. I usually make
the actual rc1 release on Sunday, but I want Sunday itself to be
pretty much quiet apart from perhaps a "oops, sorry, here's a fix that
we just noticed" kind of issues. I don't want to be taken by surprise
like this just a couple of days before I want to do the rc.
So please try to just re-send the pull, but this time with
explanations of the conflict and a pointer to the fixup for the
conflict (some people end up doing a pre-merge for me as an example,
in _addition_ to the unmerged tree they send me).
I may or may not then use the particular conflict resolution that I'm
pointed at or told about (because maybe I decide to do it my way), but
regardless it really helps to have a heads-up. And when people go to
the effort and do a "and here's a pre-merged version", I basically
*always* then end up doing something like
git checkout -b test-merge ORIG_HEAD
git pull <premerged branch>
git diff master
.. everything looks good ..
git checkout master
git branch -D test-merge
just to check that yes, we agreed (or, even more interestingly, how
our different merges differed).
Now, *most* of the time there are no conflicts at all. And then
occasionally there are trivial conflicts that just come about because
people touched the MAINTAINERS file close to each other. Don't worry
about those truly trivial ones, they certainly don't need any kind of
"here's how to resolve them" or a pre-merged tree. You could *mention*
them ("You'll get a trivial conflict with an obvious resolution in
file XYZ"), but quite frankly, even that isn't required.
So I'm not asking for some silly extra busy-work. But when linux-next
notified you about a conflict, and it wasn't just something trivial,
then *that* is when I just want to be told.
And yes, part of that "I want to be told" is literally just because I
want to see that the whole "process" worked, and that things had been
in linux-next, and people had reacted to them. Usually actually
resolving the conflict isn't all that hard, and I can always find the
linux-next discussions (like I did now). See?
Linus