From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>, linux-can@vger.kernel.org
Subject: Re: [PATCH v5 5/5] include: Move includes copied from the Linux kernel into include/linux
Date: Tue, 21 Jan 2014 13:56:04 +0100 [thread overview]
Message-ID: <20140121125604.GA26766@pengutronix.de> (raw)
In-Reply-To: <52DE5B3F.3010900@hartkopp.net>
Hello Oliver,
On Tue, Jan 21, 2014 at 12:34:23PM +0100, Oliver Hartkopp wrote:
> On 21.01.2014 10:53, Uwe Kleine-König wrote:
> > On Sat, Jan 18, 2014 at 01:18:14PM +0100, Oliver Hartkopp wrote:
> >> On 17.01.2014 21:36, Uwe Kleine-König wrote:
> > I don't see a real reason here, but I read between the lines that you
> > prefer isotp to go into the kernel directly instead of into can-utils
> > first.
>
> We obviously have different ways to think/discuss :-(
>
> - Yes, isotp is intended for mainline
> - isotp.h will not change when it goes into mainline
> - therefore can-utils can rely on the existing isotp.h
> - therefore isotp.h can stay together with other includes in can-utils
>
> IMO it does not make sense to kick out the isotp tools just because of the
> fact that isotp is not in mainline today.
Note I didn't intend to kick out the isotp stuff, I only questioned if
it's sensible to keep the isotp header seperate from the vanilla kernel
headers. And here seperate doesn't mean in a different repository but in
a different path in the same repository.
I think techically it doesn't matter much if there is a single directory
with includes or if there are two of them. Then the only difference I
see is that it's easier to sync with the kernel if you just do something
like
cd can-utils
rm some/directory
cp -a /path/to/kernel/some/directory
and then don't have to fixup because can-utils' includes contain in
some/directory a header you have to restore afterwards because it's not
part of the kernel. You probably know better if that is a relevant point
or not. It depends e.g. on answers to the questions:
- When will isotp be part of the kernel?
- How often do you have to sync the linux headers into can-utils?
Well, up to you.
> > Anyhow, what I care for is to be able to package can-utils for Debian.
>
> Yes. That would be nice indeed.
>
> > That's what I can do once the updated headers hit can-utils so IMO we
> > can stop arguing even if we don't agree 100%.
>
> I hope I was able to focus the discussion some lines before. Don't know if
> it's worth the effort to kick out the isotp stuff and merge it later on.
I would be surprised if that is sensible and as I hope to got clear now
that's not what I intended to suggest.
> > @Marc or Oliver: Can you please give me a ping as soon as the headers
> > hit your public repo. Thanks.
>
> Indeed I would vote for your latest patch set (v5) as the only missing thing
> there would be to move isotp.h from include/socketcan/can/isotp.h to
> include/linux/can/isotp.h and delete the socketcan directory then.
>
> In Marcs patch set (v6) the license updates got lost at some point.
The license updates were not included in my v5 IIRC either. I talked to
Marc earlier today and he said to care for application of v6 + a header
sync.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
prev parent reply other threads:[~2014-01-21 12:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 16:12 [PATCH v5 1/5] License cleanup Marc Kleine-Budde
2014-01-16 16:12 ` [PATCH v5 1/5] include: Remove two unused header files Marc Kleine-Budde
2014-01-16 16:12 ` [PATCH v5 2/5] ioctl.h: drop unused header Marc Kleine-Budde
2014-01-16 16:12 ` [PATCH v5 3/5] isotp.h: add explicit license information Marc Kleine-Budde
2014-01-16 16:12 ` [PATCH v5 4/5] include/socketcan: prepare headers to be moved to include/linux Marc Kleine-Budde
2014-01-16 16:12 ` [PATCH v5 5/5] include: Move includes copied from the Linux kernel into include/linux Marc Kleine-Budde
2014-01-16 19:28 ` Uwe Kleine-König
2014-01-16 22:11 ` Marc Kleine-Budde
2014-01-17 13:37 ` Uwe Kleine-König
2014-01-17 14:04 ` Marc Kleine-Budde
2014-01-17 20:36 ` Uwe Kleine-König
2014-01-18 12:18 ` Oliver Hartkopp
2014-01-21 9:53 ` Uwe Kleine-König
2014-01-21 9:59 ` Yegor Yefremov
2014-01-21 10:32 ` Uwe Kleine-König
2014-01-21 11:34 ` Oliver Hartkopp
2014-01-21 11:37 ` Marc Kleine-Budde
2014-01-21 11:51 ` Oliver Hartkopp
2014-01-21 12:56 ` Uwe Kleine-König [this message]
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=20140121125604.GA26766@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=socketcan@hartkopp.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).