All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: mszeredi@redhat.com, brauner@kernel.org, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/3] lib: Add tst_fd_iterate()
Date: Tue, 10 Oct 2023 15:23:26 +0200	[thread overview]
Message-ID: <ZSVQTs1WTxz5Bioi@yuki> (raw)
In-Reply-To: <87jzruzs6p.fsf@suse.de>

Hi!
> I don't wish to over complicate this, but how many potential fd types
> could there be 100, 1000? Some could have complicated init logic.

I'm at 25 at the moment, suprisingly all of them so far are a syscall
with a few parameters, sometimes packed in a struct.

> I'm wondering if at the outset it would be better to define an interface
> struct with name, setup and teardown for each FD type, plus whatever
> other meta-data might be useful for filtering.
> 
> Then instead of a case statement, we put the structs in an array etc.

I guess that we can, but we would have to add some private data area to
the tst_fd, so that we can tear down things cleanly, but we would need
that if we want to convert the tst_iterate_fd() to be iterator-like
anyways.

-- 
Cyril Hrubis
chrubis@suse.cz

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

WARNING: multiple messages have this Message-ID (diff)
From: Cyril Hrubis <chrubis@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: mszeredi@redhat.com, brauner@kernel.org, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/3] lib: Add tst_fd_iterate()
Date: Tue, 10 Oct 2023 15:23:26 +0200	[thread overview]
Message-ID: <ZSVQTs1WTxz5Bioi@yuki> (raw)
In-Reply-To: <87jzruzs6p.fsf@suse.de>

Hi!
> I don't wish to over complicate this, but how many potential fd types
> could there be 100, 1000? Some could have complicated init logic.

I'm at 25 at the moment, suprisingly all of them so far are a syscall
with a few parameters, sometimes packed in a struct.

> I'm wondering if at the outset it would be better to define an interface
> struct with name, setup and teardown for each FD type, plus whatever
> other meta-data might be useful for filtering.
> 
> Then instead of a case statement, we put the structs in an array etc.

I guess that we can, but we would have to add some private data area to
the tst_fd, so that we can tear down things cleanly, but we would need
that if we want to convert the tst_iterate_fd() to be iterator-like
anyways.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2023-10-10 13:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04 12:47 [LTP] [PATCH 0/3] Add tst_iterate_fd() Cyril Hrubis
2023-10-04 12:47 ` Cyril Hrubis
2023-10-04 12:47 ` [LTP] [PATCH 1/3] lib: Add tst_fd_iterate() Cyril Hrubis
2023-10-04 12:47   ` Cyril Hrubis
2023-10-04 15:21   ` [LTP] " Matthew Wilcox
2023-10-04 15:21     ` Matthew Wilcox
2023-10-10 10:18   ` [LTP] " Richard Palethorpe
2023-10-10 10:18     ` Richard Palethorpe
2023-10-10 13:23     ` Cyril Hrubis [this message]
2023-10-10 13:23       ` Cyril Hrubis
2023-10-04 12:47 ` [LTP] [PATCH 2/3] syscalls/readahead01: Make use of tst_fd_iterate() Cyril Hrubis
2023-10-04 12:47   ` Cyril Hrubis
2023-10-04 13:55   ` [LTP] " Amir Goldstein
2023-10-04 13:55     ` Amir Goldstein
2023-10-04 14:24     ` [LTP] " Cyril Hrubis
2023-10-04 14:24       ` Cyril Hrubis
2023-10-04 14:52       ` [LTP] " Jan Kara
2023-10-04 14:52         ` Jan Kara
2023-10-04 12:47 ` [LTP] [PATCH 3/3] syscalls: accept: Add tst_fd_iterate() test Cyril Hrubis
2023-10-04 12:47   ` Cyril Hrubis
2023-10-10 10:13 ` [LTP] [PATCH 0/3] Add tst_iterate_fd() Richard Palethorpe
2023-10-10 10:13   ` Richard Palethorpe
2023-10-10 13:20   ` Cyril Hrubis
2023-10-10 13:20     ` Cyril Hrubis
2023-10-11  8:42     ` Richard Palethorpe
2023-10-11  8:42       ` Richard Palethorpe
2023-10-11  8:52       ` Cyril Hrubis
2023-10-11  8:52         ` Cyril Hrubis

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=ZSVQTs1WTxz5Bioi@yuki \
    --to=chrubis@suse.cz \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=mszeredi@redhat.com \
    --cc=rpalethorpe@suse.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /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.