linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: George Spelvin <lkml@sdf.org>
Cc: Andrey Abramov <st5pub@yandex.ru>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] simple sort swap function usage improvements
Date: Mon, 1 Apr 2019 23:08:12 +0200	[thread overview]
Message-ID: <c06d9d37-bb63-c953-d390-e46cdccc1378@rasmusvillemoes.dk> (raw)
In-Reply-To: <201903301716.x2UHG23t020732@sdf.org>

[trimming cc list]

On 30/03/2019 18.16, George Spelvin wrote:
> Great work; that is indeed a logical follow-on.
> 
> Reviewed by: George Spelvin <lkml@sdf.org>
> 
> I you feel even more ambitious, you could try impementing Rasmus
> Villemoes' idea of having generic *compare* functions.  (It's on
> my to-do list, but I haven't made meaningful progress yet, and I'm
> happy to pawn it off.)
> 
> A significant fraction of the time, the sort key is a 4- or 8-byte
> integer field in a structure at a small offset from the base or
> list_head.
> 
> A function pointer < 4096 could be interpreted as encoding:
> - Key size (1 bit)
> - Key signedness (1 bit)
> - Sort direction (1 bit)
> - Offset (9 bits; +/-256 words = +/-1024 bytes, or 0..511 words from start)
> 
> With the correct level of preprocessor hackery,
> SIMPLE_CMP_ASCENDING(struct type, key_field)
> SIMPLE_LIST_CMP_ASCENDING(struct type, list_field, key_field)
> SIMPLE_CMP_DESCENDING(struct type, key_field)
> SIMPLE_LIST_CMP_DESCENDING(struct type, list_field, key_field)

So, first of all, I don't think there's any reason to do the descending
thing, at least until there's a (or better, a handful) of potential users.

Second, I don't think the user should be concerned with the encoding,
and I'd avoid the shouting, even if it happens to be implemented as
macros because of the need to do type inspection. So I'd do

  sort_by_key(base, count, key)

where base must be of type "struct foo *" and key must be the name of a
member of struct foo. [I think most would be just fine with the default
swap - if not, that could be added, or we could add another macro also
taking a swap argument.] So this would expand to

  sort(base, count, sizeof(*base), the-encoding-stuff, NULL)

Similarly, for list_sort, I'd do

  list_sort_by_key(head, type, list-member, key-member)

which would expand to

  list_sort((long)offset_diff, head, encode typeof(type->key));

The latter is the easier one to do because we have the context argument
that goes unused in the case of a trivial comparison function. The
former would be just as easy if we decide that we only care about the
majority which are happy with the default swap function, because in that
case the offsetof(type, key) could go in the swap argument, and the cmp
argument would just be the same as for list_sort. Having the two share
the logic for "key is one of the types we support, or build bug" would
be good. Perhaps the two tiny list_sort.h and sort.h headers should be
squashed.

Rasmus

      reply	other threads:[~2019-04-01 21:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30 16:37 [PATCH 0/5] simple sort swap function usage improvements Andrey Abramov
2019-03-30 16:40 ` [PATCH 1/5] arch/arc: unwind.c: replace swap function with built-in one Andrey Abramov
2019-03-30 16:41 ` [PATCH 2/5] powerpc: module_[32|64].c: " Andrey Abramov
     [not found]   ` <87zhpaox14.fsf@concordia.ellerman.id.au>
2019-04-02 19:11     ` Andrey Abramov
2019-03-30 16:42 ` [PATCH 3/5] ocfs2: dir,refcounttree,xattr: replace swap functions " Andrey Abramov
2019-03-30 16:43 ` [PATCH 4/5] ubifs: find.c: replace swap function " Andrey Abramov
2019-03-30 16:43 ` [PATCH 5/5] Lib: sort.h: replace int size with size_t size in the swap function Andrey Abramov
     [not found]   ` <20190330183826.GB21828@kroah.com>
2019-03-30 20:15     ` George Spelvin
2019-03-30 20:24       ` Greg KH
2019-03-30 21:49         ` George Spelvin
2019-03-31  7:00       ` Andrey Abramov
2019-03-31 10:54         ` gregkh
2019-04-01 14:47           ` David Laight
2019-04-01 18:01             ` Vineet Gupta
2019-04-01 18:14               ` Andrey Abramov
2019-04-01 18:22                 ` Vineet Gupta
2019-03-30 17:16 ` [PATCH 0/5] simple sort swap function usage improvements George Spelvin
2019-04-01 21:08   ` Rasmus Villemoes [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=c06d9d37-bb63-c953-d390-e46cdccc1378@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@sdf.org \
    --cc=st5pub@yandex.ru \
    /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).