From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Johannes Berg <johannes@sipsolutions.net>, backports@vger.kernel.org
Subject: Re: [PATCH RFC 1/2] Add required changes for audio packports
Date: Fri, 18 Sep 2015 08:00:45 -0500 [thread overview]
Message-ID: <55FC0AFD.9010409@linux.intel.com> (raw)
In-Reply-To: <1442560549.2168.5.camel@sipsolutions.net>
Thanks for the review.
On 9/18/15 2:15 AM, Johannes Berg wrote:
> On Thu, 2015-09-17 at 16:47 -0500, Pierre-Louis Bossart wrote:
>
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
>> +
>> +#define hrtimer_resolution (unsigned int)LOW_RES_NSEC
>> +
>> +#endif /* < 4.2 */
>
> Do we need parentheses around that all?
Yes, and this needs more love to use hr timers as well in the compat c
code. this was just to get past the compilation.
>> --- a/backport/backport-include/linux/skbuff.h
>> +++ b/backport/backport-include/linux/skbuff.h
>> @@ -258,6 +258,8 @@ static inline struct page *dev_alloc_page(void)
>> #endif /* LINUX_VERSION_CODE < KERNEL_VERSION(3,19,0) */
>>
>> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,19,0)
>> +
>> +#include <linux/uio.h>
>
> That's a bit odd? But perhaps necessary - just better to have the blank
> line after the include :)
>
>> --- /dev/null
>> +++ b/backport/backport-include/linux/uio.h
>> @@ -0,0 +1,246 @@
>> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,5,0))
>> +#include_next <linux/uio.h>
>> +
>> +#ifndef __iter_is_iovec_h_
>> +#define __iter_is_iovec_h_
>
> Perhaps better to simply protect the whole file?
>
>> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0))
>> +
>> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(3,15,0))
>> +
>> +/* iov_iter is defined elsewhere */
>> +#include_next <linux/fs.h>
>> +static inline bool iter_is_iovec(struct iov_iter *i)
>> +{
>> + return true;
>> +}
>> +
>> +#else
>> +static inline bool iter_is_iovec(struct iov_iter *i)
>> +{
>> + return !(i->type & (ITER_BVEC | ITER_KVEC));
>> +}
>> +#endif
>> +#endif
>
> That could be written a bit clearer with #elif, I think.
>
>> +#endif /* __iter_is_iovec_h_ */
>> +
>> +#else
>> +
>> +#ifndef _LINUX_UIO_H
>> +#define _LINUX_UIO_H
>>
>
> This part looks like a straight-up copy - perhaps better to add it to
> copy-list and then provide a patch to patch around it the necessary
> modifications - see for example the devcoredump patch in
> patches/backport-adjustments/devcoredump.patch
Ah this whole thing is a nightmare. The definitions moved between files,
I kept having issues between uio.h, aio.h and fs.h and warnings/errors
of the iovec/kuiocb structures being redefined. I'll look at the example
mentioned.
>> --- a/dependencies
>> +++ b/dependencies
>> @@ -178,3 +178,5 @@ IGB 3.5
>>
>> # This driver needs mmc_hw_reset() which was added in kernel version
>> 3.2
>> MWIFIEX_SDIO 3.2
>> +
>> +SOUND 3.13
>> \ No newline at end of file
>
> Please keep a newline at EOF.
yep
>> ++static ssize_t snd_pcm_aio_read(struct kiocb *iocb, const struct
>> iovec *iov,
>> ++ unsigned long nr_segs, loff_t pos)
>> ++
>
> Is it possible to reduce this function to calling the existing
> snd_pcm_readv (and aio_write to writev) by suitable data structure
> manipulation?
>
> If so, it might be possible to create an spatch to make these changes,
> which would make them apply more generally and be less prone to
> breaking.
This was a first-order ugly backport to revert to what existed before.
I have no idea what an spatch is, if there is an example of such a
'suitable data structure manipulation' I am all ears.
--
To unsubscribe from this list: send the line "unsubscribe backports" in
next prev parent reply other threads:[~2015-09-18 13:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 21:47 [PATCH RFC 0/2] addition of audio to backports Pierre-Louis Bossart
2015-09-17 21:47 ` [PATCH RFC 1/2] Add required changes for audio packports Pierre-Louis Bossart
2015-09-18 7:15 ` Johannes Berg
2015-09-18 13:00 ` Pierre-Louis Bossart [this message]
2015-09-18 13:09 ` Johannes Berg
2015-09-17 21:47 ` [PATCH RFC 2/2] add script to enable audio backport Pierre-Louis Bossart
2015-09-18 7:17 ` Johannes Berg
2015-09-18 13:06 ` Pierre-Louis Bossart
2015-09-18 13:11 ` Johannes Berg
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=55FC0AFD.9010409@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=backports@vger.kernel.org \
--cc=johannes@sipsolutions.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 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.