From: Geert Stappers <stappers@stappers.nl>
To: rust-for-linux <rust-for-linux@vger.kernel.org>
Subject: real driver
Date: Wed, 7 Jul 2021 21:18:36 +0200 [thread overview]
Message-ID: <20210707191836.nhqciiclpy4ghmj5@gpm.stappers.nl> (raw)
In-Reply-To: <YOXB7FRqldZik2Xn@kroah.com>
Previous-Subject: Re: [PATCH 00/17] Rust support
On Wed, Jul 07, 2021 at 05:02:04PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 07, 2021 at 03:07:50PM +0100, Wedson Almeida Filho wrote:
> > > Last I looked at this thing, it was not
> > > feature-complete compared to the in-kernel binder code, has that been
> > > resolved and the needed filesystem changes added?
> >
> > It is not feature-complete in comparison to the C one just yet, it is missing a
> > few things but not for any fundamental reason -- we were mostly focusing on the
> > kernel crate and tests.
>
> I love it how you call "binderfs is missing" a "few things" :)
>
> > Miguel's point is that it does implement the vast majority of binder features
> > and is non-trivial, so it could be used as evidence that useful kernel drivers
> > can be built with Rust; not just "transpiled" from C, but written with the Rust
> > safety guarantees.
>
> As Christoph said, and I and others have said before, binder is in no
> way shape or form anything that resembles any sort of "driver" at all.
> It is a crazy IPC mechanism that is tacked onto the side of the kernel.
> Not to say that it doesn't have its usages, but the interactions between
> binder and the rest of the kernel are very small and specific.
> Something that almost no one else will ever write again.
>
> Please work on a real driver to help prove, or disprove, that this all
> is going to be able to work properly. There are huge unanswered
> questions that need to be resolved that you will run into when you do
> such a thing.
Suggesting virtual null modem drivers.
At userland side are character devices visible.
These /dev/tntX come in pairs /dev/tnt0 + /dev/tnt1,
/dev/tnt2 + /dev/tnt3, /dev/tnt4 + /dev/tnt5, etcetera.
They behave like serial ports.
The driver inbetween a /dev/tntX-pair mimicks UARTs.
Yeah, still no true hardware driver.
Things this driver will bring:
* Providing character devices
* Interrupts upon recieving / transmitting characters.
* Having transmit / recieve buffers
* Timer knowlege for emulating baud rate ( speed in bits per second )
Earlier implementations exist on the Internet. I have salvaged two:
* https://gitlab.com/stappersg/tty0tty
* https://gitlab.com/stappersg/nullmodem
May this idea bring this project further.
Regards
Geert Stappers
P.S.
I want the share with you the fun / the pun I see in "Subject: real driver"
driver: that what pushes forward
:-)
--
Silence is hard to parse
next reply other threads:[~2021-07-07 19:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 19:18 Geert Stappers [this message]
2021-07-08 6:25 ` real driver Greg KH
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=20210707191836.nhqciiclpy4ghmj5@gpm.stappers.nl \
--to=stappers@stappers.nl \
--cc=rust-for-linux@vger.kernel.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 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).