All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/3] ioctl01: Add default tty device
Date: Mon, 13 Feb 2023 16:08:02 +0000	[thread overview]
Message-ID: <87zg9ho7hg.fsf@suse.de> (raw)
In-Reply-To: <20230208135404.GB31469@pevik>


Petr Vorel <pvorel@suse.cz> writes:

> Hi Li,
>
>> > +#define        DEFAULT_TTY_DEVICE      "/dev/tty0"
>
>> Hidden the device path parameter is a good idea.
>
>> But maybe can we add a function to find available char devices
>instead

There is already something like this built into the kernel; you can
create a PTY on demand with /dev/ptmx.

See the kernel/pty tests.

>> of using the tty0 as default? In that function, we do the S_ISCHR() check
>> and return the valid path of it. Then the rest test (e.g. ioctl02) can make
>> use of it but not set the specified device as well. WDYT?
>
> FYI I'm using S_ISCHR() in other patches, which check if device can be used.
> Implementing search looks like a good idea. Are useful files any /dev/tty*
> (including /dev/tty, /dev/ttyACM0, /dev/ttyS0) or should I avoid any file
> or include other paths?

These are real serial devices except /dev/tty which could be a real
device or a pty IIUC. Same goes for /dev/hvc[0-9] and possibly some
others.

I'm going to put the patch set to changes requested because /dev/tty0 is
the current virtual console. It seems the test just overwrites the
permissions and starts sending ioctls to it.

I don't know if this is safe and probably it's no different from
creating a pty.

>
> Kind regards,
> Petr


-- 
Thank you,
Richard.

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

  parent reply	other threads:[~2023-02-13 16:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 13:17 [LTP] [PATCH 0/3] ioctl01: device check, enable Petr Vorel
2023-02-07 13:17 ` [LTP] [PATCH 1/3] ioctl01: Add default tty device Petr Vorel
2023-02-08 10:13   ` Li Wang
2023-02-08 13:54     ` Petr Vorel
2023-02-08 14:13       ` Petr Vorel
2023-02-09  6:19         ` Li Wang
2023-02-09  7:30           ` Petr Vorel
2023-02-09  6:15       ` Li Wang
2023-02-09  7:22         ` Petr Vorel
2023-02-13 16:08       ` Richard Palethorpe [this message]
2023-02-13 23:25         ` Petr Vorel
2023-02-07 13:17 ` [LTP] [PATCH 2/3] ioctl01: Check " Petr Vorel
2023-02-07 13:17 ` [LTP] [PATCH 3/3] runtest/syscalls: Enable ioctl01 Petr Vorel

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=87zg9ho7hg.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    /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.