linux-kernel - Re: [PATCH RFC 3/3] char: rttyprintk: add Rust TTY printk driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGAB667MERYcWT0OrxUVrna60nKamtkrFeGGZZZwcCiGSKXTEQ@mail.gmail.com>
Date: Mon, 26 Jan 2026 22:21:56 +0900
From: 하승종 <engineer.jjhama@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Arnd Bergmann <arnd@...db.de>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 3/3] char: rttyprintk: add Rust TTY printk driver

2026년 1월 26일 (월) PM 9:53, Greg Kroah-Hartman <gregkh@...uxfoundation.org>님이 작성:
>
> On Mon, Jan 26, 2026 at 12:22:10PM +0000, SeungJong Ha via B4 Relay wrote:
> > +        let opts = tty::Options {
> > +            driver_name: c_str!("rttyprintk"),
> > +            name: c_str!("rttyprintk"),
> > +            major: tty::TTYAUX_MAJOR,
> > +            minor_start: 4,
>
> You are not documenting the "take over" of this minor number under this
> major number anywhere, which isn't ok for using a static minor number.
>

You are correct. I should have explicitly documented the takeover
of the static minor number. I'll change it dynamic.

> And while I understand the need for an example driver, the ttyprintk
> driver is a very trivial one overall, we don't need another one in the
> system as one is enough :)
>
> thanks,
>
> greg k-h

I also agree that a duplicate driver is unnecessary. It was selected only
as the simplest candidate to validate the abstractions. I agree that
a sample driver implementation (e.g. in samples/rust/) would have
been more suitable for this purpose.

Thanks,

SeungJong Ha