All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 0/4] sched_{g,s}etattr01: Add missing policies
Date: Tue, 25 Jan 2022 16:55:13 +0100	[thread overview]
Message-ID: <YfAdYd0Ju407w0wx@pevik> (raw)
In-Reply-To: <YfARoEoyhkTsWg9d@yuki>

Hi Cyril,

> Hi!
> > sched_getattr and sched_setattr are 99% identical (2 values are
> > different). I was thinking to use the same approach from e197796f22
> > ("sethostname: Convert to new API"), but not sure if it's a good
> > approach.

> Actually I do not think that the approach in sethostname is good. There
> should be a C file for each test. If they share code that should be put
> into headers or libraries.

> We used to have more tests like that that build binaries in different
> directories from a single source with different macros and I find it
> utterly confusing.
Thanks for info. Agree, it's confusing.

I guess in tests which are very simple like sethostname or even these
sched_getattr we'll just endup with duplicity, right?
Because putting one function into header which is shared with tests in different
directory is just confusing and not worth of doing.

So I can recreate sethostname01.c.

And for these tests I can make a note just to remember update struct for the
other test.

> > Do we want to reduce files needed to be updated after new policy is
> > added? If yes, shouldn't there be just a single directory?
> > (what name should be using to show 2 syscalls are in sources in this
> > directory?)

> I would vote against this.
Understand now.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

      reply	other threads:[~2022-01-25 15:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 14:40 [LTP] [PATCH v2 0/4] sched_{g,s}etattr01: Add missing policies Petr Vorel
2022-01-25 14:40 ` [LTP] [PATCH v2 1/4] lapi/sched.h: Add include <sched.h> Petr Vorel
2022-01-28 13:32   ` Cyril Hrubis
2022-01-28 13:33     ` Cyril Hrubis
2022-01-28 15:19     ` Petr Vorel
2022-01-25 14:40 ` [LTP] [PATCH v2 2/4] lapi: Move SCHED_DEADLINE definition from tests Petr Vorel
2022-01-25 15:07   ` Cyril Hrubis
2022-01-25 14:40 ` [LTP] [PATCH v2 3/4] sched_get_priority_min01: Add missing policies Petr Vorel
2022-01-25 14:46   ` Petr Vorel
2022-01-25 14:48     ` Petr Vorel
2022-01-25 15:15   ` Cyril Hrubis
2022-01-25 14:40 ` [LTP] [PATCH v2 4/4] sched_get_priority_max01: " Petr Vorel
2022-01-25 15:26   ` Cyril Hrubis
2022-01-25 15:05 ` [LTP] [PATCH v2 0/4] sched_{g,s}etattr01: " Cyril Hrubis
2022-01-25 15:55   ` Petr Vorel [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=YfAdYd0Ju407w0wx@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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.