Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1268745 > unrolled thread
| Started by | "Nicholas A. Bellinger" <nab@linux-iscsi.org> |
|---|---|
| First post | 2015-11-13 11:10 +0100 |
| Last post | 2015-11-13 21:30 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
[GIT PULL] target updates for v4.4-rc1 "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2015-11-13 11:10 +0100
Re: [GIT PULL] target updates for v4.4-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-13 18:50 +0100
Re: [GIT PULL] target updates for v4.4-rc1 "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2015-11-13 21:00 +0100
Re: [GIT PULL] target updates for v4.4-rc1 Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-13 21:30 +0100
| From | "Nicholas A. Bellinger" <nab@linux-iscsi.org> |
|---|---|
| Date | 2015-11-13 11:10 +0100 |
| Subject | [GIT PULL] target updates for v4.4-rc1 |
| Message-ID | <qujsS-52z-25@gated-at.bofh.it> |
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%) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-11-13 18:50 +0100 |
| Message-ID | <quqE2-11H-7@gated-at.bofh.it> |
| In reply to | #1268745 |
On Fri, Nov 13, 2015 at 1:59 AM, Nicholas A. Bellinger
<nab@linux-iscsi.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Nicholas A. Bellinger" <nab@linux-iscsi.org> |
|---|---|
| Date | 2015-11-13 21:00 +0100 |
| Message-ID | <qusFQ-2eI-17@gated-at.bofh.it> |
| In reply to | #1269119 |
On Fri, 2015-11-13 at 09:48 -0800, Linus Torvalds wrote: > On Fri, Nov 13, 2015 at 1:59 AM, Nicholas A. Bellinger > <nab@linux-iscsi.org> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-11-13 21:30 +0100 |
| Message-ID | <qut8T-2FM-25@gated-at.bofh.it> |
| In reply to | #1269182 |
On Fri, Nov 13, 2015 at 11:55 AM, Nicholas A. Bellinger
<nab@linux-iscsi.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web