archive mirror
 help / color / mirror / Atom feed
From: Geert Stappers <>
To: rust-for-linux <>
Subject: real driver
Date: Wed, 7 Jul 2021 21:18:36 +0200	[thread overview]
Message-ID: <> (raw)

In-Reply-To: <>
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:

May this idea bring this project further.

Geert Stappers

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

             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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).