All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yanling Song <songyl@ramaxel.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: <martin.petersen@oracle.com>, <linux-scsi@vger.kernel.org>,
	<songyl@ramaxel.com>
Subject: Re: [PATCH] spraid: initial commit of Ramaxel spraid driver
Date: Tue, 12 Oct 2021 11:10:21 +0000	[thread overview]
Message-ID: <20211012111021.5efd1b67@songyl> (raw)
In-Reply-To: <af2fa285-aa9e-72de-0f19-b3a054678ee0@acm.org>

On Mon, 11 Oct 2021 12:40:05 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> On 10/11/21 01:34, Yanling Song wrote:
> > get_unaligned_be*() is an inline which has the same function as our
> > current code and there is no difference on performance.
> > But current code is better when supporting old kernels since it is
> > implemented on SCSI spec and there is no dependency on
> > get_unaligned_be*(), which means the code can work on any version
> > of kernel.
> > So I prefer to keep current implementation. What's your opinion?  
> 
> Hi Yanling,
> 
> On all architectures I'm familiar with get_unaligned_be*() is faster 
> than fetching individual bytes and combining these with shift 
> operations. As an example, x86 CPU's support unaligned memory
> accesses and for these CPU's the Linux kernel translates
> get_unaligned_be*() into a single (potentially unaligned) memory
> access.
> 
> Kernel drivers that are submitted for upstream inclusion should use
> the upstream kernel API. Whether or not get_unaligned_be*() is
> available in older kernels does not matter - since it is available in
> the upstream kernel and since it makes code faster and easier to
> read, using that function is strongly recommended. Additionally, it
> can happen that after a driver has been accepted upstream that
> someone writes a Coccinelle script to change all open-coded
> get_unaligned_be*() calls into get_unaligned_be*() calls.
> Compatibility with older kernels would not be accepted as a valid
> argument against such a patch.
> 
> I think that get_unaligned_be*() functions are supported since kernel 
> version 2.6.26, released in 2008, 13 years ago. Does this address
> your concern about supporting older kernel versions?

Ok. Will used get_unaligned_be*() functions in the next verison.
> 
> Regarding supporting older kernel versions, a common approach is to 
> develop against the latest upstream kernel. To support older kernels, 
> include a header file called e.g. backport.h and in that header file 
> implement the latest kernel API in terms of older kernel functions.
> An example:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0) &&	\
> 	!defined(CONFIG_SUSE_KERNEL)
> static inline void bio_set_dev(struct bio *bio,
>                                 struct block_device *bdev)
> {
> 	bio->bi_bdev = bdev;
> }
> #endif

Thanks. I'll use this way when supporting older kernel.

> 
> Bart.


  reply	other threads:[~2021-10-12 11:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  3:47 [PATCH] spraid: initial commit of Ramaxel spraid driver Yanling Song
2021-09-30  5:36 ` Randy Dunlap
2021-10-01  1:03   ` Yanling Song
2021-10-01  4:15 ` Christoph Hellwig
2021-10-08  9:22   ` Yanling Song
2021-10-09  3:58 ` Bart Van Assche
2021-10-09 13:32   ` Yanling Song
2021-10-10  3:52     ` Bart Van Assche
2021-10-11  8:34       ` Yanling Song
2021-10-11 19:40         ` Bart Van Assche
2021-10-12 11:10           ` Yanling Song [this message]
2021-10-11 19:54 ` Bart Van Assche
2021-10-12 14:49   ` Yanling Song
2021-10-12 16:59     ` Bart Van Assche
2021-10-13  6:50       ` Yanling Song
2021-10-13 22:00         ` Bart Van Assche
2021-10-15  5:48           ` Yanling Song
2021-10-20  0:33           ` Yanling Song
2021-10-20  3:24             ` Bart Van Assche
2021-11-03  1:43               ` Yanling Song
2021-11-05 13:02               ` Yanling Song
2021-11-05 16:13                 ` Bart Van Assche
2021-11-06  8:30                   ` Yanling Song

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=20211012111021.5efd1b67@songyl \
    --to=songyl@ramaxel.com \
    --cc=bvanassche@acm.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /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.